DOCSLIB.ORG

Status of Cernvm

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Status of Cernvm Status of 휇CernVM D Berzano, J Blomer, P Buncic, I Charalampidis, G Ganis, G Lestaris [email protected] CERN PH-SFT 1 / 12 Introduction Production CernVM: • 2.X series, 2.7.0 ready to be released • Scientific Linux 5 based • Uses Conary package manager • Versatile image: runs on practically all hypervisors runs all LHC experiment software frameworks can take different roles (desktop, batch, head, BOINC) Next generation CernVM (휇CernVM): • Scientific Linux 6 based • Based on RPM • Drop remaining dependencies on rPath tools • Simplify the image building and distribution process Virtual appliance without a hard disk image 2 / 12 CernVM Building Blocks Classic CernVM XMPP CernVM Online CernVM Co-Pilot HTTP (Amazon EC2) cloud-init (in development) Contextualization HEPIX CernVM-FS System Libraries & rAA Tools HTTP Cache Hierarchy Fuse Operating System Kernel • Uniform and portable environment for physics data processing • Minimal operating system derived from application dependencies • Easy to maintain and to distribute 3 / 12 CernVM Building Blocks 휇CernVM XMPP CernVM Online CernVM Co-Pilot HTTP (Amazon EC2) cloud-init (in development) OS + Extras AUFS R/W Overlay HD Scratch initrd: CernVM-FS + 휇Contextualization AUFS Fuse Kernel ISO Image Prototyped by Ioannis Charalampidis Idea: Operating system on CernVM-FS Instead of 400 MB hard disk image: 10 MB ISO image + 100 MB cache. ) From “just enough operating system” to “operating system on demand” 3 / 12 휇CernVM Root File System Stack • AUFS well-maintained kernel Read/Write Scratch Area module CernVM-FS Read-Only AUFS • < 5 % performance loss (untar) (Union File System) Read/Write • Some use cases faster due to Interface CernVM-FS meta-data handling • Root file system stack created by init script on ramdisk • Tweaks required to CernVM-FS: • Closing all read-write file descriptors in order to unraval file system stack on shutdown • Redirect syslog messages to a plain file • In-flight change of DNS server (tbd.) ) This file system stack requires special support froma read-only Fuse branch in order to work. 4 / 12 휇CernVM Boot Process CernVM Kernel: 3.7.10 (tbd: next long-term kernel) Features: KSM, zRam, THP, cgroups, X32-ABI Extra modules: AUFS, VMware drivers, VBox drivers, OpenAFS “Virtualization-friendly”, minimal set of device drivers: 100 modules / 8 MB as compared to 2 000 modules / 120 MB in SL6 1 SYSLINUX boot loader 2 Decompress and load Linux kernel 3 Decompress init ramdisk, execute /init a) Start networking b) Contextualize (tbd.) c) [Partition and] [format and] mount scratch space d) Mount CernVM-FS e) Mount AUFS root file system stack 5 / 12 Booting 휇CernVM 6 / 12 Scientific Linux on CernVM-FS Naive approach: install packages with yum into CernVM-FS chroot Problem: package managers are not designed to preserve an environemnt • Scientific Linux and EPEL repositories contain newest packages The same command at a different point in time leads to a different environment • Bootstrapping an entire system is time-consuming, incremental updates depend on the order of packages • Little support for special rules Such as: use a specific package version, prefer packages from a specific repository • Dependency resolution is heuristic (not optimal) Idea: fully versioned meta RPM “closure” (dependencies resolved upfront), mirror of used packages from upstream repository 7 / 12 Build Process: Scientific Linux on CernVM-FS Maintenance of the repository must not become a Linux distributor’s job But: should be reproducible and well-documented Idea: Automatically generate a fully versioned, closed package list from an unversioned “shopping list” of packages Scientific Linux EPEL CernVM Extras (≈ 40) ··· yum install on CernVM-FS Closure !""# Dependency $%&"'# (# Formulate dependencies as Integer Linear Program (ILP) Mirror 8 / 12 Build Process: Package Dependency ILP Normalized (Integer) Linear Program: 0x11 0a11 ··· a1n 1 0x11 0b1 1 (c ··· c ) · B . C B . C · B . C ≤ B . C Minimize 1 n @ . A subject to @ . .. A @ . A @ . A xn am1 ··· amn xn bm Here: every available (package, version) is mapped to a xi 2 f0; 1g. Cost vector: newer versions are cheaper than older versions. (Obviously: less packages cheaper than more packages.) Dependencies: Package xa requires xb or xc : xb + xc − xa ≥ 0. Packages xa and xb conflict: xa + xb ≤ 1. (. ) Figures ≈17 000 available packages (n = 17000), 500 packages on “shopping list” ≈160 000 inequalities (m = 160000), solving time <10 s (glpk) Meta RPM: ≈1 000 fully versioned packages, dependency closure Idea: Mancinelli, Boender, di Cosmo, Vouillon, Durak (2006) 9 / 12 CernVM: VM Life Cycle 11. Retire 10. Feedback 2. Prepare 1. Plan 9. Terminate 8. Monitor Repositories Development Deployment Cycle Cycle 3. Build 4. Test 6. Instantiate 7. Contextualize 5. Endorse CernVM Infrastructure User Infrastructure Figure 1: Visual representation of the two sub-cycles that form the Virtual Machine Lifecycle. 10 / 12 2. The Virtual Machine Lifecycle A virtual machine passes through various different stages throughout it’s life. These stages are just a logical separation of the fundamental procedures that are common for the maintenance of every virtual machine (VM). They are usually independent and are associated with a specific set of tools. For instance, the life of the VM begins when the specifications of the build process are prepared and stored in a reference database, and it is terminated after it has completed the job it was instantiated for. In order to find an optimal solution it is important to identify those stages, the tools associated with them and their dependencies. This way the appropriate tools can be grouped with the stages and form a stand-alone and independently-maintained component. In the CernVM Project we pass through all stages of the every time we release a new version. In our case, after a VM instance completes it’s cycle, user feedback is processed and a new development cycle begins. Because of this cycling pattern, we decided to use the term lifecycle to refer to the life of CernVM. This lifecycle can be split into two logical sub-cycles: the development cycle and the deployment cycle (Figure 1). The development cycle begins with the definition of the specifications and finishes with the production of the distributable VM media. This cycle is performed entirely inside the CernVM infrastructure. The deployment cycle begins with the instantiation of the released image and finishes with the termination of the instance. This cycle is performed outside the CernVM infrastructure, such as a public or private cloud infrastructure (e.g. Amazon or OpenNebula ) or an individual computer (e.g. desktop hypervisors or a small computer farm). In all these cases, the OS needs to contact the CernVM infrastructure in order to obtain contextualization information and software packages from our repository. The two cycles are connected via two intermediate stages: The release of the produced image to the public and the feedback that is collected from the users and triggers a new development cycle. The two stages are in the borders that split the private infrastructure and the public. As was mentioned before, each stage is independent and is typically supported by a number of specialized tools. Plan: This is a stage on which the desired functionality of the VM is planned. The resulting CernVM: VM Life Cycle 11. Retire 10. Feedback 2. Prepare 1. Plan 9. Terminate 8. Monitor Repositories Development Deployment Cycle Cycle 3. Build 4. Test 6. Instantiate 7. Contextualize 5. Endorse CernVM Infrastructure User Infrastructure Avoids: Image Building Solves: Image Distribution Figure 1: Visual representation of the two sub-cycles that form the Virtual Machine Lifecycle. Options for updating: stay, diverge, rebase 2. The Virtual Machine Lifecycle 10 / 12 A virtual machine passes through various different stages throughout it’s life. These stages are just a logical separation of the fundamental procedures that are common for the maintenance of every virtual machine (VM). They are usually independent and are associated with a specific set of tools. For instance, the life of the VM begins when the specifications of the build process are prepared and stored in a reference database, and it is terminated after it has completed the job it was instantiated for. In order to find an optimal solution it is important to identify those stages, the tools associated with them and their dependencies. This way the appropriate tools can be grouped with the stages and form a stand-alone and independently-maintained component. In the CernVM Project we pass through all stages of the every time we release a new version. In our case, after a VM instance completes it’s cycle, user feedback is processed and a new development cycle begins. Because of this cycling pattern, we decided to use the term lifecycle to refer to the life of CernVM. This lifecycle can be split into two logical sub-cycles: the development cycle and the deployment cycle (Figure 1). The development cycle begins with the definition of the specifications and finishes with the production of the distributable VM media. This cycle is performed entirely inside the CernVM infrastructure. The deployment cycle begins with the instantiation of the released image and finishes with the termination of the instance. This cycle is performed outside the CernVM infrastructure, such as a public or private cloud infrastructure (e.g. Amazon or OpenNebula ) or an individual computer (e.g. desktop hypervisors or a small computer farm). In all these cases, the OS needs to contact the CernVM infrastructure in order to obtain contextualization information and software packages from our repository. The two cycles are connected via two intermediate stages: The release of the produced image to the public and the feedback that is collected from the users and triggers a new development cycle. The two stages are in the borders that split the private infrastructure and the public. As was mentioned before, each stage is independent and is typically supported by a number of specialized tools.
Load more

Recommended publications
  • Hacker Public Radio
    hpr0001 :: Introduction to HPR hpr0002 :: Customization the Lost Reason hpr0003 :: Lost Haycon Audio Aired on 2007-12-31 and hosted by StankDawg Aired on 2008-01-01 and hosted by deepgeek Aired on 2008-01-02 and hosted by Morgellon StankDawg and Enigma talk about what HPR is and how someone can contribute deepgeek talks about Customization being the lost reason in switching from Morgellon and others traipse around in the woods geocaching at midnight windows to linux Customization docdroppers article hpr0004 :: Firefox Profiles hpr0005 :: Database 101 Part 1 hpr0006 :: Part 15 Broadcasting Aired on 2008-01-03 and hosted by Peter Aired on 2008-01-06 and hosted by StankDawg as part of the Database 101 series. Aired on 2008-01-08 and hosted by dosman Peter explains how to move firefox profiles from machine to machine 1st part of the Database 101 series with Stankdawg dosman and zach from the packetsniffers talk about Part 15 Broadcasting Part 15 broadcasting resources SSTRAN AMT3000 part 15 transmitter hpr0007 :: Orwell Rolled over in his grave hpr0009 :: This old Hack 4 hpr0008 :: Asus EePC Aired on 2008-01-09 and hosted by deepgeek Aired on 2008-01-10 and hosted by fawkesfyre as part of the This Old Hack series. Aired on 2008-01-10 and hosted by Mubix deepgeek reviews a film Part 4 of the series this old hack Mubix and Redanthrax discuss the EEpc hpr0010 :: The Linux Boot Process Part 1 hpr0011 :: dd_rhelp hpr0012 :: Xen Aired on 2008-01-13 and hosted by Dann as part of the The Linux Boot Process series.
    [Show full text]
  • Happy Birthday Linux
    25 Jahre Linux! Am Anfang war der Quellcode Entstehungsgeschichte und Werdegang von Linux Entwicklung und Diversifizierung der Distributionen Der Wert von Linux oder: „Wat nix kost, dat is och nix.“ Andreas Klein ORR 2016 1 Am Anfang war der Quellcode (70er) ● 1969, Ken Thompson u. Dennis Ritchie erstellen die erste Version von Unix in Assembler. ● Von 1969-1971 entwickeln sie gemeinsam die Programmiersprache B. ● Ab 1971 erweiterte in erster Linie Dennis Ritchie B, um weitere Elemente und nannte sie Anfangs NB (new B). ● 1973 waren die Erweiterungen soweit gediehen, das er die stark verbesserte Sprache C nannte (Brian W. Kernighan hat ebenfalls maßgeblich dazu beigetragen). //Unix=25 PCs ● Bis 1974 war das gesamte Betriebssystem UNIX vollständig in C implementiert und wurde mit einem C-Compiler kostenfrei an verschiedene Universitäten verteilt. ● 1978 wurden bereits über 600 Computer mit dem UNIX-Betriebssystemen betrieben. ● Das aufblühende Zeitalter der Computerisierung der 70er Jahre war geprägt vom regen und freien Austausch von Programmen und dessen zugrunde liegenden Ideen. Sinnvoller Weise tauschte man diese als Quellcode untereinander aus. ● 1979 wurde von AT&T die letzte UNIX-Version 7, mit freiem Quellcode veröffentlicht. Andreas Klein ORR 2016 2 Am Anfang war der Quellcode (80er) ● 1980 – 1983 AT&T sowie zahlreiche andere Unternehmen beginnen mit der Kommerzialisierung von UNIX, durch Koppelung an stark beschränkenden Lizenzen und Geheimhaltung des zugrunde liegenden Quelltextes. ● Richard Stallman kündigt am 27. September 1983 in den Newsgroups net.unix-wizards und net.usoft das GNU-Projekt an. ● Am 5. Januar 1984 begann Stallman offiziell mit der Arbeit am GNU-Projekt, nachdem er seine Stelle am MIT gekündigt hatte.
    [Show full text]
  • Zenoss Developer's Guide
    Zenoss Developer’s Guide Version 2.3.3 February 19, 2009 Zenoss Developer’s Guide Version 2.3.3 Copyright © 2009 Zenoss, Inc. All rights reserved. The Zenoss logo is a registered trademark of Zenoss, Inc. Zenoss and Open Enterprise Management are trademarks of Zenoss, Inc. in the U.S. and other countries. Zenoss can be contacted at: Zenoss, Inc. 275 West St. Suite 204 Annapolis MD 21401 U.S.A. Flash is a registered trademark of Adobe Systems Incorporated. Java is a registered trademark of Sun Microsystems, Inc. Linux is a registered trademark of Linus Torvalds. SNMP Informant is a trademark of Garth K. Williams (Informant Systems, Inc.). Tomcat is a trademark of the Apache Software Foundation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries. All other companies and products mentioned are trademarks and property of their respective owners. Table of Contents 1. Introduction .............................................................................................................................. 1 1.1. Overview ...................................................................................................................... 1 1.1.1. Model ................................................................................................................ 1 1.1.2. Availability ......................................................................................................... 1 1.1.3. Events ...............................................................................................................
    [Show full text]
  • Linux Networking Cookbook™ by Carla Schroder
    Linux Networking Cookbook ™ Carla Schroder Beijing • Cambridge • Farnham • Köln • Paris • Sebastopol • Taipei • Tokyo Linux Networking Cookbook™ by Carla Schroder Copyright © 2008 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mike Loukides Indexer: John Bickelhaupt Production Editor: Sumita Mukherji Cover Designer: Karen Montgomery Copyeditor: Derek Di Matteo Interior Designer: David Futato Proofreader: Sumita Mukherji Illustrator: Jessamyn Read Printing History: November 2007: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. The Cookbook series designations, Linux Networking Cookbook, the image of a female blacksmith, and related trade dress are trademarks of O’Reilly Media, Inc. Java™ is a trademark of Sun Microsystems, Inc. .NET is a registered trademark of Microsoft Corporation. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
    [Show full text]
  • Building Linux Software with Conary
    Building Linux Software with Conary Michael K. Johnson rpath, Inc. [email protected] Abstract of Conary terminology and design, you may want to read the paper Repository-Based Sys- tem Management Using Conary, in Proceed- This paper describes best practices in Conary ings of the Linux Symposium, Volume Two, packaging: writing recipes that take advan- 2004, kept updated at http://www.rpath. tage of Conary features; avoiding redundancy com/technology/techoverview/, which with recipe inheritance and design; implement- introduces Conary’s design and vocabulary in ing release management using branches, shad- greater detail. Terms called out in boldface in ows, labels, redirects, and flavors; and design- this paper without an explicit definition are de- ing and writing dynamic tag handlers. It de- fined in that overview. scribes how Conary policy prevents common packaging errors. It provides examples from our rpath Linux distribution, illustrating the de- sign principles of the Conary build process. It 1 Conary Source Management then describes the steps needed to create a new distribution based on the rpath Linux distribu- Unlike legacy package management tools, tion, using the distributed branch and shadow Conary has integral management for source features of Conary. code and binaries, and the binaries are directly associated with the source code from which Conary is a distributed software management they have been built. system for Linux distributions. Based on exten- sive experience developing Linux distributions Conary stores source files in source compo- and package management tools, it replaces tra- nents, and then uses a recipe (described later) ditional package management solutions (such to build binary components that it can in- as RPM and dpkg) with one designed to enable stall on a system.
    [Show full text]
  • Cernvm – a Virtual Software Appliance for LHC Applications
    17th International Conference on Computing in High Energy and Nuclear Physics (CHEP09) IOP Publishing Journal of Physics: Conference Series 219 (2010) 042003 doi:10.1088/1742-6596/219/4/042003 CernVM – a virtual software appliance for LHC applications P Buncic1, C Aguado Sanchez1, J Blomer1, L Franco1, A Harutyunian2,3, P Mato1, Y Yao3 1 CERN, 1211 Geneve 23, Geneva, Switzerland 2Armenian e-Science Foundation, Yerevan, Armenia 3Yerevan Physics Institute after A.I. Alikhanyan, Yerevan, Armenia 4 Lawrence Berkeley National Laboratory, 1 Cyclotron Road, CA 94720 Abstract. CernVM is a Virtual Software Appliance capable of running physics applications from the LHC experiments at CERN. It aims to provide a complete and portable environment for developing and running LHC data analysis on any end-user computer (laptop, desktop) as well as on the Grid, independently of Operating System platforms (Linux, Windows, MacOS). The experiment application software and its specific dependencies are built independently from CernVM and delivered to the appliance just in time by means of a CernVM File System (CVMFS) specifically designed for efficient software distribution. The procedures for building, installing and validating software releases remains under the control and responsibility of each user community. We provide a mechanism to publish pre-built and configured experiment software releases to a central distribution point from where it finds its way to the running CernVM instances via the hierarchy of proxy servers or content delivery networks. In this paper, we present current state of CernVM project and compare performance of CVMFS to performance of traditional network file system like AFS and discuss possible scenarios that could further improve its performance and scalability.
    [Show full text]
  • Zenoss Zeveloper's Guide Version
    Zenoss, Inc. www.zenoss.com Copyright © 2008 Zenoss, Inc., 275 West St. Suite 204, Annapolis, MD 21401, U.S.A. All rights reserved. The Zenoss logo is a registered trademark of Zenoss, Inc. Zenoss and Open Enterprise Management are trademarks of Zenoss, Inc. in the U.S. and other countries. Flash is a registered trademark of Adobe Systems Incorporated. Java is a registered trademark of Sun Microsystems, Inc. Linux is a registered trademark of Linus Torvalds. SNMP Informant is a trademark of Garth K. Williams (Informant Systems, Inc.). Tomcat is a trademark of the Apache Software Foundation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries. All other companies and products mentioned are trademarks and property of their respective owners. Zenoss Developer’s Guide for Version 2.3 Zenoss Developer’s Guide for Version 2.3 Table of Contents 1. Introduction ............................................................................................................................... 1 1.1. Overview ........................................................................................................................ 1 1.1.1. Model ................................................................................................................. 1 1.1.2. Availability .......................................................................................................... 1 1.1.3. Events ................................................................................................................
    [Show full text]
  • The Future of Continuous Integration in GNOME
    The Future of Continuous Integration in GNOME Colin Walters Germán Poo-Caamaño Daniel M. German Red Hat, MA, USA University of Victoria, Canada University of Victoria, Canada GNOME Project GNOME Project [email protected] [email protected] [email protected] Abstract—In Free and Open Source Software (FOSS) projects In [1], Michlmayr et al. revealed three different types of based on Linux systems, the users usually install the software release management that occur in FOSS projects: development from distributions. The distributions act as intermediaries be- releases, major end-user stable releases, and minor releases tween software developers and users. Distributors collect the source code of the different projects and package them, ready (that update existing end-user releases). The major focus of to be installed by the users. Packages seems to work well for release management in FOSS managing and distributing stable major and minor releases. It has been in the last two, that in Linux systems is mainly presents, however, various release management challenges for done by distributors, leaving the first one up to the developers, developers of projects with multiples dependencies not always available in the stable version of their systems. In projects like who are considered experts. GNOME, composed of dozens of individual components, devel- Distributions, such as Ubuntu and SUSE, use packages to opers must build newer versions of the libraries and applications deliver software to their users. Unfortunately, the package that their applications depend upon before working in their own model has restrictions for development. Packages are not projects. This process can be cumbersome for developers who are not programmers, such as user interaction designers or technical created by distributions at the same pace as a software is writers.
    [Show full text]
  • Ellsworth American
    — : Tl ells 1 February 1 1 11 * “vw«.•%*"*™*-■; worth, Maine, Thursday, i:j, iw t AT ELLMWoKTIi POST OKKICK. * ni-whki 7 .loumisimrnts. LOCAL AFFAIRS. tin- h ! the lynx was treed, lie whs Highest of all in Leavening Tower.— Latest U. S. Gov't Report brought to the ground by a bullet from Mr. (ides* rifle. lie was a fellow si:\\ \l»\I Uil'l Ml Ms IIIIS \VK» K. large •• •• men stir 11 r about three f♦«■ ♦ from his nos* **:al<uu i,t Ni i^ara I it fn*» to t b» t of his short tui.. CE® 1 I- l''ter~ N ■■! ,.f force Insure’ •I. T u-hnian >licrifl"s -nlr-. He- Is-! of the series of icon I \' > noth K-t h.irle-t .1 Morrill. stercopt DaVaE V <t> Ur. lit Mcri anM!.- |- A M Ins Co. Icctuns m the Congregational chureh. -1 l K re M a rI nc I n § Co "bull nave so •• proven will be Kairs i,o>> as i,mh»‘si. C. C. BURRILL & !’ I»uf*• *i n iif for,•••losure. pojiular, SON. I:.»11• I» I; « u-lmiaii "Mukeol r.ayside." given s (Thursday; evening. The Solicited. Bkooki.in, Mi subject of tiie lecture will be of Corrp«pondrnrf IM. I .SWOItTI I Ml' “Home,” <ii'oi... I atoii Not; of f,,r« ■ -ure. (vvl! which many line views of Home of the 1.1 \\ M »N ABSOLUTELY PURE present day will be shown. Ten selected The Mm iiiiuf Sun. IAIUIAI. 1.1ST <‘t views famous will be shown 0 Mim i.i iMan s statuary before tin a short KLLSWORTII FALLS.
    [Show full text]
  • Deliverable Due Date : 1.11.2009 Start Date of Project : 01.01.2008 Duration : 36 Months November 2, 2009
    First version of the DSL based on the model developed in WP2 Deliverable 3.2 Nature : Deliverable Due date : 1.11.2009 Start date of project : 01.01.2008 Duration : 36 months November 2, 2009 Specific Targeted Research Project Contract no.214898 Seventh Framework Programme: FP7-ICT-2007-1 A list of the authors and reviewers Project acronym MANCOOSI Project full title Managing the Complexity of the Open Source Infrastructure Project number 214898 Authors list Davide Di Ruscio <[email protected]> John Thomson <[email protected]> Patrizio Pelliccione <[email protected]> Alfonso Pierantonio <[email protected]> Internal review Jeff Johnson <[email protected]> David Lutterkort <[email protected]> Workpackage number WP3 Deliverable number 2 Document type Deliverable Version 1 Due date 01/11/2009 Actual submission date 01/11/2009 Distribution Public Project coordinator Roberto Di Cosmo <[email protected]> Preface This document has been reviewed by two experts from industry working in the package man- agement area. They were chosen specifically for their experience and knowledge of topics that are addressed in this document. By doing this, we can be relatively assured that the proposed mechanisms and the DSL have covered sufficient grounds for the first version. Another reason for this selection is that they have detailed knowledge of implementing DSLs in practical sys- tems and as such allow us to be confident that the approach can be adopted by industry and not be solely a research topic. We would like to acknowledge their help and feedback which was invaluable not only for input into this document but also for enhancing our approach and how we will implement it in the scope of the rest of the Mancoosi project.
    [Show full text]
  • Antes De Empezar
    Antes de empezar... ● Láminas (y quizás video) en bureado.com ● Aplicaciones->Accesorios->Terminal – sudo aptitude update – sudo aptitude install gems – gems-client 10.2.205.219 ● Aplicaciones->Accesorios->Terminal – sudo aptitude install dpkg-dev devscripts Taller de empaquetamiento de software bajo el sistema APT José Miguel Parrella Romero (bureado) Debian Developer Problemática ● La mayoría del software libre crece de forma orgánica, generando un problema de acceso ● ca 1993 se empezó a atender el problema de la distribución de software libre al público ● En 1998, Debian libera APT: Advanced Packaging Tool como propuesta – Facilitar la distribución de software libre – Hacer elegante y escalable la distribución – Hoy en día, el sistema de paquetes más usado Otros sistemas de paquetes ● Derivados de APT ● Sistemas agnósticos (ipkg/opkg, Fink) postmodernos ● RPM y frontends – PackageKit contemporáneos – Conary usados en Red Hat, – Smart SuSe y derivados – ZeroInstall ● Paquetes basados – CoApp en fuentes como – Ponga su nombre Arch (pacman) y aquí... también Slackware (swaret) Objetivos funcionales ● Ubicar un pedazo de software en cualquier parte del mundo, en demanda – If you can't apt-get it, it isn't useful or doesn't exist ● Encargarse de conseguir y preparar todas las dependencias para el software ● Instalar el software para su uso inmediato ● Preconfigurar el software, opcionalmente de acuerdo a instrucciones del usuario ● Gestionar actualizaciones y remociones Componentes de APT Paquete Repo fuente ● Paquetes binarios físicos (.deb) ● Build Paquetes fuentes daemon físicos (.dsc, .tar.gz) Listas de paquetes ● Listas de paquetes (Release y Packages[.*]) ● Repositorios (HTTP, Developers FTP, SSH...) Paquetes binarios Escenarios (objetivos) ● Reconstruir un paquete de software existente con nuevas opciones y/o cambios ● Crear un paquete de software para una nueva aplicación ● Discusión sobre otros escenarios (si el tiempo lo permite) – Aplicaciones Web – Módulos de lenguajes (Perl, Python...) ● Buenos ciudadanos en Debian (y Ubuntu) Buscando las fuentes..
    [Show full text]
  • Zenoss Installation for Core Version
    Zenoss, Inc. www.zenoss.com Zenoss Installation for Core 2.4 Copyright © 2009 Zenoss, Inc., 275 West St. Suite 204, Annapolis, MD 21401, U.S.A. All rights reserved. This work is licensed under a Creative Commons Attribution Share Alike 3.0 License. To view a copy of this license, visit http:// creativecommons.org/licenses/by-sa/3.0/; or send a letter to Creative Commons, 171 2nd Street, Suite 300, San Francisco, California, 94105, USA. The Zenoss logo is a registered trademark of Zenoss, Inc. Zenoss and Open Enterprise Management are trademarks of Zenoss, Inc. in the U.S. and other countries. Flash is a registered trademark of Adobe Systems Incorporated. Java is a registered trademark of Sun Microsystems, Inc. Linux is a registered trademark of Linus Torvalds. Oracle and the Oracle logo are registered trademarks of the Oracle Corporation. SNMP Informant is a trademark of Garth K. Williams (Informant Systems, Inc.). Sybase is a registered trademark of Sybase, Inc. Tomcat is a trademark of the Apache Software Foundation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries. All other companies and products mentioned are trademarks and property of their respective owners. 1. Installing Zenoss for RHEL 5 or CentOS 5 .......................................................................................... 1 1.1. Prerequisite Tasks ................................................................................................................... 1 1.2. Install the Zenoss Software .....................................................................................................
    [Show full text]