Linux Fanatic Since the Early 1990S

Total Page:16

File Type:pdf, Size:1020Kb

Load more

Professional Xen® Virtualization Acknowledgments .........................................................................................ix Introduction ................................................................................................ xix Chapter 1: Overview of Virtualization .............................................................. 1 Chapter 2: Introduction to Xen ..................................................................... 27 Chapter 3: Obtaining and Installing Xen........................................................ 57 Chapter 4: Booting and Configuring a Xen Host ............................................ 87 Chapter 5: Configuring and Booting Virtual Machines ................................. 117 Chapter 6: Building Filesystems for Virtual Machines ................................. 141 Chapter 7: Managing and Monitoring Virtual Machines ............................... 175 Chapter 8: Xen Networking ........................................................................ 201 Chapter 9: Advanced Virtual Machine Configuration ................................... 231 Chapter 10: Using Xen in the Data Center .................................................. 283 Appendix A: xm Command and Option Reference ........................................ 339 Appendix B: Xen Virtual Machine Configuration File Reference ................... 383 Index ........................................................................................................ 391 fffirs.inddfirs.indd i 112/14/072/14/07 44:35:45:35:45 PPMM fffirs.inddfirs.indd iiii 112/14/072/14/07 44:35:46:35:46 PPMM Professional Xen® Virtualization William von Hagen Wiley Publishing, Inc. fffirs.inddfirs.indd iiiiii 112/14/072/14/07 44:35:46:35:46 PPMM Professional Xen® Virtualization Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-0-470-13811-3 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 Library of Congress Cataloging-in-Publication Data is available from the publisher. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read. For general information on our other products and services please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Wrox Programmer to Programmer, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. Xen is a registered trademark of XenSource, Inc. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. fffirs.inddfirs.indd iivv 112/14/072/14/07 44:35:47:35:47 PPMM For Dorothy, my wife and best friend. As always, and forever. fffirs.inddfirs.indd v 112/14/072/14/07 44:35:47:35:47 PPMM About the Author William von Hagen (Bill) has been a UNIX system administrator for over 20 years and a Linux fanatic since the early 1990s. He has worked as a systems programmer, system administrator, writer, applications developer, drummer, and documentation manager. Bill has written or co-written books on such topics as Ubuntu Linux, GCC, Linux server hacks, Linux filesystems, SUSE Linux, Red Hat Linux, SGML, Mac OS X, and hacking the TiVo. He has also written numerous articles on Linux, embedded computing, Mac OS X, Unix, and open source technology. fffirs.inddfirs.indd vvii 112/14/072/14/07 44:35:47:35:47 PPMM Credits Acquisitions Editor Production Manager Jenny Watson Tim Tate Senior Development Editor Vice President and Executive Group Publisher Tom Dinse Richard Swadley Technical Editors Vice President and Executive Publisher Dan Magenheimer Joseph B. Wikert Richard Artz Project Coordinator, Cover Production Editor Lynsey Stanford Eric Charbonneau Proofreader Copy Editor Kathryn Duggan Nancy Rapoport Indexer Editorial Manager Johnna VanHoose Dinse Mary Beth Wakefield fffirs.inddfirs.indd vviiii 112/14/072/14/07 44:35:47:35:47 PPMM fffirs.inddfirs.indd vviiiiii 112/14/072/14/07 44:35:47:35:47 PPMM Acknowledgments First, I’d like to thank my wife and best friend forever, Dorothy Fisher, who has been more supportive than any human could be expected to be. Fish, the best day of my life was the day I met you! There’s no way to thank you enough for the life that I have today. Next, friends like Jim Morgan, Dr. Joe O’Lear, Larry Rippel, and Kim Walter are an amazing bonus to life itself. Similarly, incredible relatives such as Morgan Gable, Elise Platz, and Luke Platz are the real hope of the future. My life is richer for having all of you as a part of it. Lucky me, indeed! Thanks to Dan Magenheimer and Richard Artz, who did the technical edit on this book, and made it far better than it would have been without their insightful involvement. Thanks to Kit Kemper, ex-Wiley, who helped me promote the idea for this book in the first place, and thanks to the amazing (and patient) people at Wiley who helped make it a reality: Tom Dinse, Carol Long, Rebekah Gholdson, Jenny Watson, and others that I probably don’t even know. It takes a team to create a book, and I’m lucky to have worked with all of you. All errors and omissions are mine alone, but this book would be poorer without all of your contributions. fffirs.inddfirs.indd iixx 112/14/072/14/07 44:35:47:35:47 PPMM fffirs.inddfirs.indd x 112/14/072/14/07 44:35:48:35:48 PPMM Contents Acknowledgments ix Introduction xix Chapter 1: Overview of Virtualization 1 What Is Virtualization? 2 Application Virtualization 2 Desktop Virtualization 3 Network Virtualization 3 Server and Machine Virtualization 4 Storage Virtualization 7 System-Level or Operating System Virtualization 9 Why Virtualization Today? 10 Basic Approaches to Virtual Systems 11 Advantages of Virtualization 15 Better Use of Existing Hardware 15 Reduction in New Hardware Costs 16 Reduction in IT Infrastructure Costs 16 Simplified System Administration 17 Increased Uptime and Faster Failure Recovery 18 Simplified Capacity Expansion 18 Simpler Support for Legacy Systems and Applications 18 Simplified System-Level Development 19 Simplified System Installation and Deployment 20 Simplified System and Application Testing 20 Virtualization Caveats 21 Single Point of Failure Problems 21 Server Sharing and Performance Issues 22 Per-Server Network Congestion 23 Increase in Networking Complexity and Debugging Time 23 Increased Administrative Complexity 24 Identifying Candidates for Virtualization 24 Summary 26 fftoc.inddtoc.indd xxii 112/14/072/14/07 44:37:03:37:03 PPMM Contents Chapter 2: Introduction to Xen 27 History of Xen 27 Overview of Xen and x86 Virtualization 29 X86 Protection Levels: One Ring to Rule Them All 30 X86 Protection Levels and Virtualization 31 Xen Domains and the Hypervisor 32 Interacting with the Hypervisor 33 Controlling Hypervisor Scheduling 33 Advanced Topics in Operating System Schedulers 34 Types of Virtual Machines Supported by Xen 35 Paravirtualized Systems 36 Unmodified Guest Systems 36 Combining 32-Bit and 64-Bit Kernels, Filesystems, and Applications 37 Popular Xen and Virtualization Resources on the Internet 38 Other Popular Virtualization Software 39 FreeVPS 40 Kernel Virtual Machine 40 Linux-VServer
Recommended publications
  • What Are the Problems with Embedded Linux?

    What Are the Problems with Embedded Linux?

    What Are the Problems with Embedded Linux? Every Operating System Has Benefits and Drawbacks Linux is ubiquitous. It runs most internet servers, is inside Android* smartphones, and is used on millions of embedded systems that, in the past, ran Real-Time Operating Systems (RTOSes). Linux can (and should) be used were possible for embedded projects, but while it gives you extreme choice, it also presents the risk of extreme complexity. What, then, are the trade-offs between embedded Linux and an RTOS? In this article, we cover some key considerations when evaluating Linux for a new development: ■ Design your system architecture first ■ What is Linux? ■ Linux vs. RTOSes ■ Free software is about liberty—not price ■ How much does Embedded Linux cost? ■ Why pay for Embedded Linux? ■ Should you buy Embedded Linux or roll-your-own (RYO)? ■ To fork or not to fork? ■ Software patching ■ Open source licensing ■ Making an informed decision The important thing is not whether Linux or an RTOS is “the best,” but whether either operating system—or both together—makes the most technical and financial sense for your project. We hope this article helps you make an informed decision. Design Your System Architecture First It is important to design your system architecture first—before choosing either Linux or an RTOS—because both choices can limit architectural freedom. You may discover that aspects of your design require neither Linux nor an RTOS, making your design a strong candidate for a heterogeneous approach that includes one or more bare-metal environments (with possibly a Linux and/or RTOS environment as well).
  • Study of File System Evolution

    Study of File System Evolution

    Study of File System Evolution Swaminathan Sundararaman, Sriram Subramanian Department of Computer Science University of Wisconsin {swami, srirams} @cs.wisc.edu Abstract File systems have traditionally been a major area of file systems are typically developed and maintained by research and development. This is evident from the several programmer across the globe. At any point in existence of over 50 file systems of varying popularity time, for a file system, there are three to six active in the current version of the Linux kernel. They developers, ten to fifteen patch contributors but a single represent a complex subsystem of the kernel, with each maintainer. These people communicate through file system employing different strategies for tackling individual file system mailing lists [14, 16, 18] various issues. Although there are many file systems in submitting proposals for new features, enhancements, Linux, there has been no prior work (to the best of our reporting bugs, submitting and reviewing patches for knowledge) on understanding how file systems evolve. known bugs. The problems with the open source We believe that such information would be useful to the development approach is that all communication is file system community allowing developers to learn buried in the mailing list archives and aren’t easily from previous experiences. accessible to others. As a result when new file systems are developed they do not leverage past experience and This paper looks at six file systems (Ext2, Ext3, Ext4, could end up re-inventing the wheel. To make things JFS, ReiserFS, and XFS) from a historical perspective worse, people could typically end up doing the same (between kernel versions 1.0 to 2.6) to get an insight on mistakes as done in other file systems.
  • Lguest a Journey of Learning the Linux Kernel Internals

    Lguest a Journey of Learning the Linux Kernel Internals

    Lguest A journey of learning the Linux kernel internals Daniel Baluta <[email protected]> What is lguest? ● “Lguest is an adventure, with you, the reader, as a Hero” ● Minimal 32-bit x86 hypervisor ● Introduced in 2.6.23 (October, 2007) by Rusty Russel & co ● Around 6000 lines of code ● “Relatively” “easy” to understand and hack on ● Support to learn linux kernel internals ● Porting to other architectures is a challenging task Hypervisor types make Preparation ● Guest ○ Life of a guest ● Drivers ○ virtio devices: console, block, net ● Launcher ○ User space program that sets up and configures Guests ● Host ○ Normal linux kernel + lg.ko kernel module ● Switcher ○ Low level Host <-> Guest switch ● Mastery ○ What’s next? Lguest overview make Guest ● “Simple creature, identical to the Host [..] behaving in simplified ways” ○ Same kernel as Host (or at least, built from the same source) ● booting trace (when using bzImage) ○ arch/x86/boot/compressed/head_32.S: startup_32 ■ uncompresses the kernel ○ arch/x86/kernel/head_32.S : startup_32 ■ initialization , checks hardware_subarch field ○ arch/x86/lguest/head_32.S ■ LGUEST_INIT hypercall, jumps to lguest_init ○ arch/x86/lguest/boot.c ■ once we are here we know we are a guest ■ override privileged instructions ■ boot as normal kernel, calling i386_start_kernel Hypercalls struct lguest_data ● second communication method between Host and Guest ● LHCALL_GUEST_INIT ○ hypercall to tell the Host where lguest_data struct is ● both Guest and Host publish information here ● optimize hypercalls ○ irq_enabled
  • HTTP-FUSE Xenoppix

    HTTP-FUSE Xenoppix

    HTTP-FUSE Xenoppix Kuniyasu Suzaki† Toshiki Yagi† Kengo Iijima† Kenji Kitagawa†† Shuichi Tashiro††† National Institute of Advanced Industrial Science and Technology† Alpha Systems Inc.†† Information-Technology Promotion Agency, Japan††† {k.suzaki,yagi-toshiki,k-iijima}@aist.go.jp [email protected], [email protected] Abstract a CD-ROM. Furthermore it requires remaking the entire CD-ROM when a bit of data is up- dated. The other solution is a Virtual Machine We developed “HTTP-FUSE Xenoppix” which which enables us to install many OSes and ap- boots Linux, Plan9, and NetBSD on Virtual plications easily. However, that requires in- Machine Monitor “Xen” with a small bootable stalling virtual machine software. (6.5MB) CD-ROM. The bootable CD-ROM in- cludes boot loader, kernel, and miniroot only We have developed “Xenoppix” [1], which and most part of files are obtained via Internet is a combination of CD/DVD bootable Linux with network loopback device HTTP-FUSE “KNOPPIX” [2] and Virtual Machine Monitor CLOOP. It is made from cloop (Compressed “Xen” [3, 4]. Xenoppix boots Linux (KNOP- Loopback block device) and FUSE (Filesys- PIX) as Host OS and NetBSD or Plan9 as Guest tem USErspace). HTTP-FUSE CLOOP can re- OS with a bootable DVD only. KNOPPIX construct a block device from many small block is advanced in automatic device detection and files of HTTP servers. In this paper we describe driver integration. It prepares the Xen environ- the detail of the implementation and its perfor- ment and Guest OSes don’t need to worry about mance. lack of device drivers.
  • ECE 598 – Advanced Operating Systems Lecture 19

    ECE 598 – Advanced Operating Systems Lecture 19

    ECE 598 { Advanced Operating Systems Lecture 19 Vince Weaver http://web.eece.maine.edu/~vweaver [email protected] 7 April 2016 Announcements • Homework #7 was due • Homework #8 will be posted 1 Why use FAT over ext2? • FAT simpler, easy to code • FAT supported on all major OSes • ext2 faster, more robust filename and permissions 2 btrfs • B-tree fs (similar to a binary tree, but with pages full of leaves) • overwrite filesystem (overwite on modify) vs CoW • Copy on write. When write to a file, old data not overwritten. Since old data not over-written, crash recovery better Eventually old data garbage collected • Data in extents 3 • Copy-on-write • Forest of trees: { sub-volumes { extent-allocation { checksum tree { chunk device { reloc • On-line defragmentation • On-line volume growth 4 • Built-in RAID • Transparent compression • Snapshots • Checksums on data and meta-data • De-duplication • Cloning { can make an exact snapshot of file, copy-on- write different than link, different inodles but same blocks 5 Embedded • Designed to be small, simple, read-only? • romfs { 32 byte header (magic, size, checksum,name) { Repeating files (pointer to next [0 if none]), info, size, checksum, file name, file data • cramfs 6 ZFS Advanced OS from Sun/Oracle. Similar in idea to btrfs indirect still, not extent based? 7 ReFS Resilient FS, Microsoft's answer to brtfs and zfs 8 Networked File Systems • Allow a centralized file server to export a filesystem to multiple clients. • Provide file level access, not just raw blocks (NBD) • Clustered filesystems also exist, where multiple servers work in conjunction.
  • Lguest the Little Hypervisor

    Lguest the Little Hypervisor

    Lguest the little hypervisor Matías Zabaljáuregui [email protected] based on lguest documentation written by Rusty Russell note: this is a draft and incomplete version lguest introduction launcher guest kernel host kernel switcher don't have time for: virtio virtual devices patching technique async hypercalls rewriting technique guest virtual interrupt controller guest virtual clock hw assisted vs paravirtualization hybrid virtualization benchmarks introduction A hypervisor allows multiple Operating Systems to run on a single machine. lguest paravirtualization within linux kernel proof of concept (paravirt_ops, virtio...) teaching tool guests and hosts A module (lg.ko) allows us to run other Linux kernels the same way we'd run processes. We only run specially modified Guests. Setting CONFIG_LGUEST_GUEST, compiles [arch/x86/lguest/boot.c] into the kernel so it knows how to be a Guest at boot time. This means that you can use the same kernel you boot normally (ie. as a Host) as a Guest. These Guests know that they cannot do privileged operations, such as disable interrupts, and that they have to ask the Host to do such things explicitly. Some of the replacements for such low-level native hardware operations call the Host through a "hypercall". [ drivers/lguest/hypercalls.c ] high level overview launcher /dev/lguest guest kernel host kernel switcher Launcher main() some implementations /dev/lguest write → initialize read → run guest Launcher main [ Documentation/lguest/lguest.c ] The Launcher is the Host userspace program which sets up, runs and services the Guest. Just to confuse you: to the Host kernel, the Launcher *is* the Guest and we shall see more of that later.
  • How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise

    How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise

    How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise Abstract This paper will document a process to create a custom Live CD for secure remote incident handling on Windows and Linux systems. The process will include how to configure SSH for remote access to the Live CD even when running behind a NAT device. The combination of customization and secure remote access will make this process valuable to incident handlers working in enterprise environments with limited remote IT support. Bert Hayes, [email protected] How to Create a Custom Live CD for Remote Incident Handling 2 Table of Contents Abstract ...........................................................................................................................................1 1. Introduction ............................................................................................................................5 2. Making Your Own Customized Debian GNU/Linux Based System........................................7 2.1. The Development Environment ......................................................................................7 2.2. Making Your Dream Incident Handling System...............................................................9 2.3. Hardening the Base Install.............................................................................................11 2.3.1. Managing Root Access with Sudo..........................................................................11 2.4. Randomizing the Handler Password at Boot Time ........................................................12
  • Understanding Full Virtualization, Paravirtualization, and Hardware Assist

    Understanding Full Virtualization, Paravirtualization, and Hardware Assist

    VMware Understanding Full Virtualization, Paravirtualization, and Hardware Assist Contents Introduction .................................................................................................................1 Overview of x86 Virtualization..................................................................................2 CPU Virtualization .......................................................................................................3 The Challenges of x86 Hardware Virtualization ...........................................................................................................3 Technique 1 - Full Virtualization using Binary Translation......................................................................................4 Technique 2 - OS Assisted Virtualization or Paravirtualization.............................................................................5 Technique 3 - Hardware Assisted Virtualization ..........................................................................................................6 Memory Virtualization................................................................................................6 Device and I/O Virtualization.....................................................................................7 Summarizing the Current State of x86 Virtualization Techniques......................8 Full Virtualization with Binary Translation is the Most Established Technology Today..........................8 Hardware Assist is the Future of Virtualization, but the Real Gains Have
  • Tree-Like Distributed Computation Environment with Shapp Library

    Tree-Like Distributed Computation Environment with Shapp Library

    information Article Tree-Like Distributed Computation Environment with Shapp Library Tomasz Gałecki and Wiktor Bohdan Daszczuk * Institute of Computer Science, Warsaw University of Technology, 00-665 Warsaw, Poland; [email protected] * Correspondence: [email protected]; Tel.: +48-22-234-78-12 Received: 30 January 2020; Accepted: 1 March 2020; Published: 3 March 2020 Abstract: Despite the rapidly growing computing power of computers, it is often insufficient to perform mass calculations in a short time, for example, simulation of systems for various sets of parameters, the searching of huge state spaces, optimization using ant or genetic algorithms, machine learning, etc. One can solve the problem of a lack of computing power through workload management systems used in local networks in order to use the free computing power of servers and workstations. This article proposes raising such a system to a higher level of abstraction: The use in the .NET environment of a new Shapp library that allows remote task execution using fork-like operations from Portable Operating System Interface for UNIX (POSIX) systems. The library distributes the task code, sending static data on which task force is working, and individualizing tasks. In addition, a convenient way of communicating distributed tasks running hierarchically in the Shapp library was proposed to better manage the execution of these tasks. Many different task group architectures are possible; we focus on tree-like calculations that are suitable for many problems where the range of possible parallelism increases as the calculations progress. Keywords: workload management; remote fork; distributed computations; task group communication 1.
  • Deliverable No. 5.3 Techniques to Build the Cloud Infrastructure Available to the Community

    Deliverable No. 5.3 Techniques to Build the Cloud Infrastructure Available to the Community

    Deliverable No. 5.3 Techniques to build the cloud infrastructure available to the community Grant Agreement No.: 600841 Deliverable No.: D5.3 Deliverable Name: Techniques to build the cloud infrastructure available to the community Contractual Submission Date: 31/03/2015 Actual Submission Date: 31/03/2015 Dissemination Level PU Public X PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services) Grant Agreement no. 600841 D5.3 – Techniques to build the cloud infrastructure available to the community COVER AND CONTROL PAGE OF DOCUMENT Project Acronym: CHIC Project Full Name: Computational Horizons In Cancer (CHIC): Developing Meta- and Hyper-Multiscale Models and Repositories for In Silico Oncology Deliverable No.: D5.3 Document name: Techniques to build the cloud infrastructure available to the community Nature (R, P, D, O)1 R Dissemination Level (PU, PP, PU RE, CO)2 Version: 1.0 Actual Submission Date: 31/03/2015 Editor: Manolis Tsiknakis Institution: FORTH E-Mail: [email protected] ABSTRACT: This deliverable reports on the technologies, techniques and configuration needed to install, configure, maintain and run a private cloud infrastructure for productive usage. KEYWORD LIST: Cloud infrastructure, OpenStack, Eucalyptus, CloudStack, VMware vSphere, virtualization, computation, storage, security, architecture. The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement no 600841. The author is solely responsible for its content, it does not represent the opinion of the European Community and the Community is not responsible for any use that might be made of data appearing therein.
  • The Linux 2.4 Kernel's Startup Procedure

    The Linux 2.4 Kernel's Startup Procedure

    The Linux 2.4 Kernel’s Startup Procedure William Gatliff 1. Overview This paper describes the Linux 2.4 kernel’s startup process, from the moment the kernel gets control of the host hardware until the kernel is ready to run user processes. Along the way, it covers the programming environment Linux expects at boot time, how peripherals are initialized, and how Linux knows what to do next. 2. The Big Picture Figure 1 is a function call diagram that describes the kernel’s startup procedure. As it shows, kernel initialization proceeds through a number of distinct phases, starting with basic hardware initialization and ending with the kernel’s launching of /bin/init and other user programs. The dashed line in the figure shows that init() is invoked as a kernel thread, not as a function call. Figure 1. The kernel’s startup procedure. Figure 2 is a flowchart that provides an even more generalized picture of the boot process, starting with the bootloader extracting and running the kernel image, and ending with running user programs. Figure 2. The kernel’s startup procedure, in less detail. The following sections describe each of these function calls, including examples taken from the Hitachi SH7750/Sega Dreamcast version of the kernel. 3. In The Beginning... The Linux boot process begins with the kernel’s _stext function, located in arch/<host>/kernel/head.S. This function is called _start in some versions. Interrupts are disabled at this point, and only minimal memory accesses may be possible depending on the capabilities of the host hardware.
  • Question Bank Mca Semester V Vol. I

    Question Bank Mca Semester V Vol. I

    QUESTION BANK MCA SEMESTER V VOL. I 1 FOR PRIVATE CIRCULATION The Questions contained in this booklet have been prepared by the faculty of the Institute from the sources believed to be reliable. Neither the Institute nor the faculty gives any guarantee with respect to completeness or accuracy of the contents contained in the booklet and shall in no event be liable for any errors, omissions or damages arising out of use of the matter contained in the booklet. The Institute and the faculty specifically disclaim any implied warranty as to merchantability or fitness of the information for any particular purpose. 2 QUESTION BANK LINUX PROGRAMMING MCA 301 3 QUESTION BANK LINUX PROGRAMMING - MCA 301 MCA V UNIT - I I Test Your Skills: (a) State Whether the Following Statements are True or False: 1 The “no” option informs the machine that there is no grace period or time to wait for other users to log off. 2 Telnet command is used for changing the run level or state of the computer without rebooting. 3 IP address is a unique identifier for the system. 4 Transmission control protocol (TCP) builds on top of UPS and certifies that each message has been received. 5 Cron is known for arranging the files in the disk in chronological manner. 6 ARP (Address Resolution Protocol) converts IP address to MAC Address. 7 UNIX is a command-based system. 8 A program is synonymous with a process. 9 All UNIX flavors today offer a Command User Interface. 10 The operating system allocates memory for the program and loads the program to the allocated memory.