DOCSLIB.ORG

LOCUS Distributed Operating System I

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
LOCUS Distributed Operating System I The LOCUS Distributed Operating System I Bruce Walker, Gerald Popek, Robert English, Charles Kline and Greg Thiel 2 University of California at Los Angeles Abstract system supports a very high degree of network tran- sparency, i.e. it makes the network of machines ap- LOCUS Is a distributed operating system pear to users and programs as a single computer; which supports transparent access to data machine boundaries are completely hidden during through a network wide fllesystem, permits normal operation. Both files and programs can be automatic replication of storaget supports moved dynamically with no effect on naming or transparent distributed process execution, correct operation. Remote resources are accessed in supplies a number of high reliability functions the same manner as local ones. Processes can be such as nested transactions, and is upward created locally and remotely in the same manner, compatible with Unix. Partitioned operation and process interaction is the same, independent of of subnetl and their dynamic merge is also location. Many of these functions operate tran- supported. sparently even across heterogeneous cpus. The system has been operational for about LOCUS also provides a number of high reliability two years at UCLA and extensive experience facilities, including flexible and automatic replication In its use has been obtained. The complete of storage at a file level, a full implementation of system architecture is outlined in this paper, nested transactions[MEUL 83], uad a substantially and that experience is summarized. more robust data storage facility than conventional Unix systems. All of the functions reported here 1 Introduction have been implemented, and most are in routine use. LOCUS is a Unix compatible, distributed operat- This paper provides an overview of the basic ing system in operational use at UCLA on a set of 17 LOCUS system architecture. The file system, espe- Vax/750's connected by a standard Ethernet s The cially its distributed naming catalog, plays a central role in the system structure, both because file system activity typically predominates in most operating 1 This research was supported by the Advanced Research systems and so high performance is critical, and be- Projects Agency under research contract DSS-MDA-903- cause the generalized name service provided is used 82-C-0189. by so many other parts of the system. Therefore, Current address of Bruce Walker, Charles Kline and the file system is described first. Remote processes Greg Thiel: LOCUS Computing Corporation, 3330 Ocean are discussed next, including discussions of process Park Blvd., Santa Monica, Ca. 90405. creation, inter-process functions and error handling. Initial work was done on DEC PDP-11/45's and VAX An important part of the LOCUS research con- 750's using both 1 and 10 megabit ring networks. cerns recovery from failures of parts of the system, including partition of a LOCUS system into separated Permission to copy without fee all or part of this material is granted but functioning subnetworks. The next sections of provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the this paper discuss the several LOCUS facilities dedi- publication and its date appear, and notice is given that copying is by cated to recovery. First is the merging of the nam- permission of the Association for Computing Machinery. To copy ing catalog; the hierarchical directory system. The otherwise, or to republish, requires a fee and/or specific permission. handling of other object types in the file system is also briefly considered. These recovery algorithms '©1983 ACM 0-89791-115-6/83/010/0049 $00.75 49 are designed to permit normal operation while A substantial amount of the LOCUS filesystem resources are arriving and departing. Last, the pro- design, as well as implementation, has been devoted tocols which LOCUS sites execute in order to main- to appropriate forms of error and failure manage- tain and define the accessible members of a network, ment. These issues will be discussed throughout this i.e. the network topology, are discussed. These pro- paper. Further, high performance has always been a tocols are designed to assure that all sites converge critical goal. In our view, solutions to all the other on the same answer in a rapid manner. problems being addressed are really not solutions at all unless their performance is suitable. In LOCUS, The paper concludes with a set of observations when resources are local, access is no more expensive regarding the use of LOCUS in production settings, than on a conventional Unix system. When especially the value of its network transparent inter- resources are remote, access cost is higher, but face. dramatically better than traditional layered file transfer and remote terminal protocols permit. 2 Distributed Fllesystem Measured performance results are presented in [GOLD 83]. S.I Filesystem overview The LOCUS filesystem presents a single tree 2.2 File Replication structured naming hierarchy to users and applica- tions. It is functionally a superset of the Unix tree 2.2.1 Motivation for Replication structured naming system. There are three major Replication of storage in a distributed filesystem areas of extension. First, the single tree structure in serves multiple purposes. First, from the users' point LOCUS covers all objects in the filesystem on all of view, multiple copies of data resources provide the machines. LOCUS names are fully transparent; it is opportunity for substantially increased availability. not possible from the name of a resource to discern This improvement is clearly the ease for read access, its location in the netwol'k. Such location tran- although the situation is more complex when update sparency is critical for allowing data and programs in is desired, since if some of the copies are not accessi- general to move or even be executed from different ble at a given instant, potential inconsistency prob- sites. The second direction of extension concerns re- lems may preclude update, thereby decreasing avai- plication. Files in LOCUS can be replicated to vary- lability as the level of replication is increased. ing degrees, and it is the LOCUS system's responsibil- ity to keep all copies up to date, assure that access The second advantage, from the user viewpoint, requests are served by the most recent available ver- concerns performance. If users of the file exist on sion, and support partitioned operation. different machines, and copies are available near those machines, then read access can be substantially To a first approximation, the pathname tree is faster compared to the necessity to have one of the made up of a collection of filegroups, as in a conven- users always make remote accesses. This difference tional Unix environment 1. Each group is a wholly can be substantial; in a slow network, it is self contained subtree of the naming hierarchy, in- overwhelming, but in a high speed local network it is cluding storage for all files and directories contained still significant 1. in the subtree. Gluing together a collection of file- groups to construct the uniform naming tree is done In a general purpose distributed computing en- via the mount mechanism. Logically mounting a file- vironment, such as LOCUS, some degree of replica- group attaches one tree (the filegroup being mount- tion is essential in order for the user to be able to ed} as a subtree within an already mounted tree. work at all. Certain files used to set up the user's The glue which allows smooth path traversals up and environment must be available even when various down the expanded naming tree is kept as operating machines have failed or are inaccessible. The start- system state information. Currently this state infor- up files in Multics, or the various Unix shells, are ob- mation is replicated at all sites. To scale a LOCUS network to hundreds or thousands of sites, this "mount" information would be cached. 1 In the LOCUS system, which is highly optimized for remote access, the cpu overhead of accessing a remote page is twice local access, and the cost of a remote open is 1 The term filegroup in this paper corresponds directly to significantly more than the case when the entire open can the Unix term filesystem. be done locally. 50 vious examples. Mail aliases and routing information greater, so one would have less directory replication are others. Of course, these cases can generally be to improve performance. handled by read-only replication, which in general The performance tradeoffs between update/read imposes fewer problems 1. rates and degree of replication are well known, and From the system point of view, some form of re- we have already discussed them. However, there are plication is more than convenient; it is absolutely other costs as well. For example, concurrency con- essential for system data structures, both for availa- trol becomes more expensive. Without replication bility and performance. Consider a file directory. A the storage site can provide concurrency control for hierarchical name space in a distributed environment the object since it will know about all activity. implies that some directories will have entries which With replication some more complex algorithm must refer to files on different machines. There is strong be supported. In a similar way, with replication, a motivation for storing a copy of all the directory en- choice must be made as to which copy of an object tries in the backward path from a file at the site will supply service when there is activity on the ob- where the file is stored, or at least "nearby". The ject. This degree of freedom is not available without principal reason is availability. If a directory entry replication. If objects move, then, in the no replica- in the naming path to a file is not accessible because tion case, the mapping mechanism must be more of network partition or site failure, then that file general.
Load more

Recommended publications
  • Sprite File System There Are Three Important Aspects of the Sprite ®Le System: the Scale of the System, Location-Transparency, and Distributed State
    Naming, State Management, and User-Level Extensions in the Sprite Distributed File System Copyright 1990 Brent Ballinger Welch CHAPTER 1 Introduction ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ This dissertation concerns network computing environments. Advances in network and microprocessor technology have caused a shift from stand-alone timesharing systems to networks of powerful personal computers. Operating systems designed for stand-alone timesharing hosts do not adapt easily to a distributed environment. Resources like disk storage, printers, and tape drives are not concentrated at a single point. Instead, they are scattered around the network under the control of different hosts. New operating system mechanisms are needed to handle this sort of distribution so that users and application programs need not worry about the distributed nature of the underlying system. This dissertation explores the approach of centering a distributed computing environment around a shared network ®le system. The ®le system is chosen as a starting point because it is a heavily used service in stand-alone systems, and the read/write para- digm of the ®le system is a familiar one that can be applied to many system resources. The ®le system described in this dissertation provides a distributed name space for sys- tem resources, and it provides remote access facilities so all resources are available throughout the network. Resources accessible via the ®le system include disk storage, other types of peripheral devices, and user-implemented service applications. The result- ing system is one where resources are named and accessed via the shared ®le system, and the underlying distribution of the system among a collection of hosts is not important to users.
    [Show full text]
  • Darwin Release 3.0.1
    Using Darwin Release 3.0.1 Thinking Machines Corporation First printing, May 1998 The information in this document is subject to change without notice and should not be construed as a commitment by Thinking Machines Corporation. Thinking Machines reserves the right to make changes to any product described herein. Although the information in this document has been reviewed and is believed to be reliable, Thinking Machines Corporation assumes no liability for errors in this document. Thinking Machines does not assume any liability arising from the application or use of any information or product described herein. Thinking Machines and Darwin are registered trademarks of Thinking Machines Corporation. Note: Darwin" is a registered trademark of Thinking Machines Corporation in the United States. Darwin" is a registered trademark of Science in Finance Ltd. in the United Kingdom. Therefore Darwin" is not available from Thinking Machines Corporation in the United Kingdom. In the United Kingdom, Thinking Machines Corporation sells its product under the name LoyaltyStream." HPĆUX and HPĆUX 10.20 are trademarks of HewlettĆPackard Company. INFORMIX is a trademark of Informix Software, Inc. InstallShield is a trademark of InstallShield Corporation. INTERSOLV is a trademark of INTERSOLV, Inc. Microsoft, Windows, Windows NT, and Windows 95 are trademarks of Microsoft Corporation. Oracle is a trademark of Oracle Corporation. Open Windows is a trademark of Sun Microsystems, Inc. Sun, Solaris, Sun Ultra, Ultra, and Sun Workstation are trademarks of Sun Microsystems, Inc. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc., in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
    [Show full text]
  • Cygwin User's Guide
    Cygwin User’s Guide Cygwin User’s Guide ii Copyright © Cygwin authors Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this per- mission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this documentation under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this documentation into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. Cygwin User’s Guide iii Contents 1 Cygwin Overview 1 1.1 What is it? . .1 1.2 Quick Start Guide for those more experienced with Windows . .1 1.3 Quick Start Guide for those more experienced with UNIX . .1 1.4 Are the Cygwin tools free software? . .2 1.5 A brief history of the Cygwin project . .2 1.6 Highlights of Cygwin Functionality . .3 1.6.1 Introduction . .3 1.6.2 Permissions and Security . .3 1.6.3 File Access . .3 1.6.4 Text Mode vs. Binary Mode . .4 1.6.5 ANSI C Library . .4 1.6.6 Process Creation . .5 1.6.6.1 Problems with process creation . .5 1.6.7 Signals . .6 1.6.8 Sockets . .6 1.6.9 Select . .7 1.7 What’s new and what changed in Cygwin . .7 1.7.1 What’s new and what changed in 3.2 .
    [Show full text]
  • UNIX Text Processing Tools—Programs for Sorting, Compar- Ing, and in Various Ways Examining the Contents of Text Files
    UNIX® TEXT PROCESSING DALE DOUGHERTY AND TIM O’REILLY and the staffofO’Reilly & Associates, Inc. CONSULTING EDITORS: Stephen G. Kochan and PatrickH.Wood HAYDEN BOOKS ADivision of HowardW.Sams & Company 4300 West 62nd Street Indianapolis, Indiana 46268 USA Copyright © 1987 Dale Dougherty and Tim O’Reilly FIRST EDITION SECOND PRINTING — 1988 INTERNET "UTP Revival" RELEASE — 2004 The UTP RevivalRelease is distributed according to the terms of the Creative Commons Attribution License. A copyofthe license is available at http://creativecommons.org/licenses/by/1.0 International Standard Book Number: 0-672-46291-5 Library of Congress Catalog Card Number: 87-60537 Trademark Acknowledgements All terms mentioned in this book that are known to be trademarks or service marks are listed below. Nei- ther the authors nor the UTP Revivalmembers can attest to the accuracyofthis information. Use of a term in this book should not be regarded as affecting the validity of anytrademark or service mark. Apple is a registered trademark and Apple LaserWriter is a trademark of Apple Computer,Inc. devps is a trademark of Pipeline Associates, Inc. Merge/286 and Merge/386 are trademarks of Locus Computing Corp. DDL is a trademark of Imagen Corp. Helvetica and Times Roman are registered trademarks of Allied Corp. IBM is a registered trademark of International Business Machines Corp. Interpress is a trademark of Xerox Corp. LaserJet is a trademark of Hewlett-Packard Corp. Linotronic is a trademark of Allied Corp. Macintosh is a trademark licensed to Apple Computer,Inc. Microsoft is a registered trademark of Microsoft Corp. MKS Toolkit is a trademark of Mortice Kern Systems, Inc.
    [Show full text]
  • Distributed Virtual Machines: a System Architecture for Network Computing
    Distributed Virtual Machines: A System Architecture for Network Computing Emin Gün Sirer, Robert Grimm, Arthur J. Gregory, Nathan Anderson, Brian N. Bershad {egs,rgrimm,artjg,nra,bershad}@cs.washington.edu http://kimera.cs.washington.edu Dept. of Computer Science & Engineering University of Washington Seattle, WA 98195-2350 Abstract Modern virtual machines, such as Java and Inferno, are emerging as network computing platforms. While these virtual machines provide higher-level abstractions and more sophisticated services than their predecessors from twenty years ago, their architecture has essentially remained unchanged. State of the art virtual machines are still monolithic, that is, they are comprised of closely-coupled service components, which are thus replicated over all computers in an organization. This crude replication of services forms one of the weakest points in today’s networked systems, as it creates widely acknowledged and well-publicized problems of security, manageability and performance. We have designed and implemented a new system architecture for network computing based on distributed virtual machines. In our system, virtual machine services that perform rule checking and code transformation are factored out of clients and are located in enterprise- wide network servers. The services operate by intercepting application code and modifying it on the fly to provide additional service functionality. This architecture reduces client resource demands and the size of the trusted computing base, establishes physical isolation between virtual machine services and creates a single point of administration. We demonstrate that such a distributed virtual machine architecture can provide substantially better integrity and manageability than a monolithic architecture, scales well with increasing numbers of clients, and does not entail high overhead.
    [Show full text]
  • “Add-On-Packages” in R Installation and Administration
    R Installation and Administration Version 2.15.3 Patched (2013-03-03) R Core Team Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the con- ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the R Core Team. Copyright c 2001{2012 R Core Team ISBN 3-900051-09-7 i Table of Contents 1 Obtaining R ::::::::::::::::::::::::::::::::::::: 1 1.1 Getting and unpacking the sources ::::::::::::::::::::::::::::: 1 1.2 Getting patched and development versions :::::::::::::::::::::: 1 1.2.1 Using Subversion and rsync:::::::::::::::::::::::::::::::: 1 2 Installing R under Unix-alikes ::::::::::::::::: 3 2.1 Simple compilation ::::::::::::::::::::::::::::::::::::::::::::: 3 2.2 Help options ::::::::::::::::::::::::::::::::::::::::::::::::::: 4 2.3 Making the manuals:::::::::::::::::::::::::::::::::::::::::::: 4 2.4 Installation :::::::::::::::::::::::::::::::::::::::::::::::::::: 6 2.5 Uninstallation :::::::::::::::::::::::::::::::::::::::::::::::::: 8 2.6 Sub-architectures::::::::::::::::::::::::::::::::::::::::::::::: 8 2.6.1 Multilib
    [Show full text]
  • The Kdiff3 Handbook the Kdiff3 Handbook
    The KDiff3 Handbook The KDiff3 Handbook 2 Contents 1 Introduction 7 1.1 Yet Another Diff Frontend? . .7 1.2 Screenshots and Features . .7 1.3 More Features . .9 1.3.1 Line-By-Line And Char-By-Char Diff-Viewer . .9 1.3.2 See White-Space Differences At One Glance . .9 1.3.3 Triple-Diff . .9 1.3.4 Comfortable Merge Of Two Or Three Input Files . 10 1.3.5 And ... 10 2 File Comparison And Merge 11 2.1 Command-Line Options . 11 2.1.1 Comparing 2 files: . 11 2.1.2 Merging 2 files: . 11 2.1.3 Comparing 3 files: . 11 2.1.4 Merging 3 files: . 11 2.1.5 Special case: Files with the same name . 11 2.1.6 Commandline for starting a folder comparison or merge: . 12 2.1.7 Other command line options . 12 2.1.8 Ignorable command line options . 12 2.2 Open-Dialog . 13 2.3 Paste and Drop Input . 13 2.4 Comparing Files And Interpreting The Information In The Input Windows . 14 2.4.1 Info Line . 14 2.4.2 Coloring . 14 2.4.3 Summary Column . 15 2.4.4 Overview Column . 15 2.4.5 Manually Aligning Lines . 15 2.4.6 Manually Joining and Splitting Diff Sections . 15 2.5 Merging And The Merge Output Editor Window . 16 2.5.1 The Summary Column . 16 The KDiff3 Handbook 2.5.2 Setting The Current Group And Synchronising Merge And Diff View Position 16 2.5.3 Choosing Inputs A, B or C For Current Conflict And Editing .
    [Show full text]
  • Installation Guide
    Installation Guide Installation Guide Schrödinger Suite 2011 Schrödinger Press Installation Guide Copyright © 2011 Schrödinger, LLC. All rights reserved. While care has been taken in the preparation of this publication, Schrödinger assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. Canvas, CombiGlide, ConfGen, Epik, Glide, Impact, Jaguar, Liaison, LigPrep, Maestro, Phase, Prime, PrimeX, QikProp, QikFit, QikSim, QSite, SiteMap, Strike, and WaterMap are trademarks of Schrödinger, LLC. Schrödinger and MacroModel are registered trademarks of Schrödinger, LLC. MCPRO is a trademark of William L. Jorgensen. Desmond is a trademark of D. E. Shaw Research. Desmond is used with the permission of D. E. Shaw Research. All rights reserved. This publication may contain the trademarks of other companies. Schrödinger software includes software and libraries provided by third parties. For details of the copyrights, and terms and conditions associated with such included third party software, see the Legal Notices, or use your browser to open $SCHRODINGER/docs/html/third_party_legal.html (Linux OS) or %SCHRODINGER%\docs\html\third_party_legal.html (Windows OS). This publication may refer to other third party software not included in or with Schrödinger software ("such other third party software"), and provide links to third party Web sites ("linked sites"). References to such other third party software or linked sites do not constitute an endorsement by Schrödinger, LLC. Use of such other third party software and linked sites may be subject to third party license agreements and fees. Schrödinger, LLC and its affiliates have no responsibility or liability, directly or indirectly, for such other third party software and linked sites, or for damage resulting from the use thereof.
    [Show full text]
  • Workstation Operating Systems Mac OS 9
    15-410 “Now that we've covered the 1970's...” Plan 9 Nov. 25, 2019 Dave Eckhardt 1 L11_P9 15-412, F'19 Overview “The land that time forgot” What style of computing? The death of timesharing The “Unix workstation problem” Design principles Name spaces File servers The TCP file system... Runtime environment 3 15-412, F'19 The Land That Time Forgot The “multi-core revolution” already happened once 1982: VAX-11/782 (dual-core) 1984: Sequent Balance 8000 (12 x NS32032) 1985: Encore MultiMax (20 x NS32032) 1990: Omron Luna88k workstation (4 x Motorola 88100) 1991: KSR1 (1088 x KSR1) 1991: “MCS” paper on multi-processor locking algorithms 1995: BeBox workstation (2 x PowerPC 603) The Land That Time Forgot The “multi-core revolution” already happened once 1982: VAX-11/782 (dual-core) 1984: Sequent Balance 8000 (12 x NS32032) 1985: Encore MultiMax (20 x NS32032) 1990: Omron Luna88k workstation (4 x Motorola 88100) 1991: KSR1 (1088 x KSR1) 1991: “MCS” paper on multi-processor locking algorithms 1995: BeBox workstation (2 x PowerPC 603) Wow! Why was 1995-2004 ruled by single-core machines? What operating systems did those multi-core machines run? The Land That Time Forgot Why was 1995-2004 ruled by single-core machines? In 1995 Intel + Microsoft made it feasible to buy a fast processor that fit on one chip, a fast I/O bus, multiple megabytes of RAM, and an OS with memory protection. Everybody could afford a “workstation”, so everybody bought one. Massive economies of scale existed in the single- processor “Wintel” universe.
    [Show full text]
  • Distributed Operating Systems
    Distributed Operating Systems ANDREW S. TANENBAUM and ROBBERT VAN RENESSE Department of Mathematics and Computer Science, Vrije Universiteit, Amsterdam, The Netherlands Distributed operating systems have many aspects in common with centralized ones, but they also differ in certain ways. This paper is intended as an introduction to distributed operating systems, and especially to current university research about them. After a discussion of what constitutes a distributed operating system and how it is distinguished from a computer network, various key design issues are discussed. Then several examples of current research projects are examined in some detail, namely, the Cambridge Distributed Computing System, Amoeba, V, and Eden. Categories and Subject Descriptors: C.2.4 [Computer-Communications Networks]: Distributed Systems-network operating system; D.4.3 [Operating Systems]: File Systems Management-distributed file systems; D.4.5 [Operating Systems]: Reliability-fault tolerance; D.4.6 [Operating Systems]: Security and Protection-access controls; D.4.7 [Operating Systems]: Organization and Design-distributed systems General Terms: Algorithms, Design, Experimentation, Reliability, Security Additional Key Words and Phrases: File server INTRODUCTION more convenient to use than the bare ma- chine. Examples of well-known centralized Everyone agrees that distributed systems (i.e., not distributed) operating systems are are going to be very important in the future. CP/M,’ MS-DOS,’ and UNIX.3 Unfortunately, not everyone agrees on A distributed operating system is one that what they mean by the term “distributed looks to its users like an ordinary central- system.” In this paper we present a view- ized operating system but runs on multi- point widely held within academia about ple, independent central processing units what is and is not a distributed system, we (CPUs).
    [Show full text]
  • Awingu-4.3-Admin-Guide.Pdf
    Awingu Admin Guide Version 4.3 1 1. Document Guidance . 3 2. Installation . 4 2.1 Connectivity Requirements . 5 2.2 Sizing & Scaling Requirements . 7 2.3 Deployment . 11 2.3.1 Deployment on Microsoft Hyper-V . 12 2.3.2 Deployment on VMware ESXi with vSphere Client on Windows . 21 2.3.3 Deployment on VMware ESXi with vSphere Web Client . 33 2.3.4 Deployment on Linux KVM . 40 2.3.5 Deployment on Microsoft Azure . 48 2.3.6 Deployment on Amazon EC2 . 49 2.3.7 Deployment on Google Compute . 50 2.4 Awingu Installer . 51 2.5 Azure Awingu All-In-One . 57 3. System Settings . 62 3.1 System Settings - Global . 63 3.1.1 Connectivity Settings . 64 3.1.2 General Information . 68 3.1.3 Service Management Settings . 72 3.1.4 Domain Settings . 74 3.1.5 Certificate Settings . 77 3.1.6 Troubleshoot . 80 3.2 System Settings - Configure . 84 3.2.1 Branding Configuration . 85 3.2.2 Feature Configuration . 88 3.2.3 User Connector Configuration . 91 3.3 System Settings - Manage . 99 3.3.1 Application Management . 100 3.3.2 Application Server Management . 114 3.3.3 Category Management . 117 3.3.4 Drive Management . 118 3.3.5 File Type Management . 121 3.3.6 Label Management . 123 3.3.7 User Management . 128 3.4 System Settings - Change Log . 129 3.5 Service Provider Support in Awingu . 131 4. Monitoring and Reporting . 137 4.1 Status Overview of Services on All Servers . 138 4.2 Monitoring Servers and Components .
    [Show full text]
  • DOCUMENT RESUME Focus on the Customer. New Opportunities for 81P
    DOCUMENT RESUME ED 401 858 HE 029 711 TITLE Focus on the Customer. New Opportunities for Partnering, CAUSE94. Track II. INSTITUTION CAUSE, Boulder, Colo. PUB DATE 95 NOTE 81p.; In: New Opportunities for Partnering. Proceedings of the 1994 CAUSE Annual Conference (Orlando, Florida, November 29-December 2, 1994); see HE 029 709. AVAILABLE FROM CAUSE Information Resources Library, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80303 (Individual papers available to CAUSE members at cost of reproduction). PUB TYPE Reports Descriptive (141) Speeches/Conference Papers (150) EDRS PRICE MF01/PC04 Plus Postage. DESCRIPTORS College Administration; College Libraries; Colleges; *Computer Networks; Computers; Cooperation; Cooperative Programs; Educational Planning; Higher Education; *Information Management; *Information Networks; Information Systems; *Information Technology; Models; *Partnerships in Education; Student Personnel Services; Universities IDENTIFIERS Boston College MA; Campus Wide Information Systems; *CAUSE National Conference; *Customer Relations; Maricopa County Community College District AZ; Southwest Texas State University ABSTRACT Eight papers are presented from the 1994 CAUSE conference track on customer-centered partnering within and among higher education institutions in regard to information resources and technology. The papers include:(1) "Customer-Centered Collaboration: Libraries and IT," which focuses on the use of teams, total quality management, and business process reengineering (Geri Bunker and Barbara Horgan);(2) "Making Order Out of Chaos with a Computerized Lottery," which discusses the use of a class scheduling lottery at the Massachusetts Institute of Technology (Steven Anders Oakland); (3) "Customers as Partners in the Information Technology Planning Process," which describes the development of the Information Technology Planning Project at the University of Minnesota (Linda Jorn and others);(4) "Distance Education: What's Up," which focuses on new trends in distance education (Gene T.
    [Show full text]