DOCSLIB.ORG

Saltstack-Formulas Documentation Release Master

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

SaltStack-Formulas Documentation Release master salt-formulas contributors Nov 12, 2018 Contents 1 Overview 1 2 Contents 3 2.1 Project Introduction...........................................3 2.2 Development Documentation...................................... 488 2.3 Installation and Operations Manual................................... 525 3 Indices and tables 549 i ii CHAPTER 1 Overview This project provides scalable and reliable IT automation using SaltStack for installing and operating wide variety of services and resources. Project provides standards to define service models and processes with ability to reuse these components in varying contexts. 1 SaltStack-Formulas Documentation, Release master 2 Chapter 1. Overview CHAPTER 2 Contents 2.1 Project Introduction Here you will find documentation relevant to architecture and goals of the project. Existing formula ecosystem and undelying metadata standards. 2.1.1 Overview Chapter 1. Overview Home SaltStack-Formulas Project Introduction Project Objectives • Collateral Goodies Project provides standards to define service models and processes with ability to reuse these components in varying contexts. Metadata model shared accross all services let us explore underlying relationships that ease the management of infrastructures acoross whole life-span. The project has little different objectives compare to official salt-formulas. The general orientation of project may be similar to the official salt formulas but the major differences lie at meta-data model and clear decomposition which being consistent accross all formulas in SaltStack- Formulas project. Collateral Goodies Adhering to the standards allows further services to be declared and configured in dynamic way, consuming metadata of surrounding services. This include following domains: 3 SaltStack-Formulas Documentation, Release master • Dynamic monitoring: Event collecting, telemetry with dashboards, alarms with notifications • Dynamic backup: Data backuping and restoring • Dynamic security: Firewall rules, router configurations • Dynamic documentation, topology visualizations • Dynamic audit profiles and beacons All these can be generated out of your existing infrastructure without need for any further parametrisation. • Documentation Home • Project Introduction • Installation and Operations Manual • Development Documentation Home SaltStack-Formulas Project Introduction Project History • Beginnings • tcp cloud Era • openstack-salt Project • saltstack-formulas Project Beginnings The initial formula structure was created in 2013. The formulas were not even called formulas back then, but states. It was time of great confusion and the quality of newly created salt-formulas was low. tcp cloud Era The majority of formulas were rewritten to current standard structure and were used in production for cloud deploy- ments. All the formulas were open-sourced and support metadata were instroduces in 2015. openstack-salt Project OpenStack-Salt project was OpenStack Big Tent initiative project in 2015/16 and provided resources for installing and operating OpenStack deployments. It used subset of the formulas and project was abandoned when tcp cloud was bought by Mirantis. 4 Chapter 2. Contents SaltStack-Formulas Documentation, Release master saltstack-formulas Project The scope of current project is much wider than management of OpenStack installations and provides generic formula ecosystem capable of managing multiple heterogenous infrastructures. • Documentation Home • Project Introduction • Installation and Operations Manual • Development Documentation Home SaltStack-Formulas Project Introduction Introduction to SaltStack • Pillar Metadata SaltStack-Formulas uses Salt configuration platform to install and manage infrastructures. Salt is an automation plat- form that greatly simplifies system and application deployment. Salt uses service formulas to define resources written in the YAML language that orchestrate the individual parts of system into the working entity. Pillar Metadata Pillar is an interface for Salt designed to offer global values that are distributed to all minions. The ext_pillar option allows for any number of external pillar interfaces to be called to populate the pillar data. Pillars are tree-like structures of data defined on the Salt Master and passed through to the minions. They allow confidential, targeted data to be securely sent only to the relevant minion. Pillar is therefore one of the most important systems when using Salt. • Documentation Home • Project Introduction • Installation and Operations Manual • Development Documentation • Documentation Home • Project Introduction • Installation and Operations Manual • Development Documentation 2.1. Project Introduction 5 SaltStack-Formulas Documentation, Release master 2.1.2 Quick Start Chapter 2. Quick start Home SaltStack-Formulas Project Introduction Deployment Preparation Guidelines • Salt Master Formulas • Salt Master Metadata Let’s consider simple deployment of single configuration node with one application and one database node. • Config node [salt master] • Application node [python app] • Database node [postgres db] To start the simple deployment you need first setup the Salt master. Installation of salt minions on controlled nodes is then very simple. Salt Master Formulas States are delivered by formulas and are stored in /srv/salt/env/<env>/ directory. Environment can be either production [prd] or development [dev]. This directory is correlates with salt_files root for given environment. You can serve multiple environments from single salt master at once, but this setup is not recommentded. Usually production environment formulas are delivered by packages and development environment formulas are de- livered by git sourced formulas. /srv/salt/env/<env>/ |-- service1/ | |-- itit.sls | |-- role1/ | | |-- service.sls | | `-- resource.sls | `-- role2.sls `-- service2/ |-- itit.sls `-- role.sls For example basic linux, python-app and openssh services for development environment in a little shortened version. /srv/salt/env/dev/ |-- linux/ | |-- itit.sls | |-- system/ | | |-- repo.sls | | `-- user.sls | `-- network/ | |-- interface.sls | `-- host.sls (continues on next page) 6 Chapter 2. Contents SaltStack-Formulas Documentation, Release master (continued from previous page) |-- python-app/ | |-- itit.sls | |-- server.sls `-- openssh/ |-- itit.sls |-- server.sls `-- client.sls More about structure and layout of the formulas can be found in Development documentation. Salt Master Metadata Metadata then define what state formulas in given specific context are projected to managed nodes. Following trees shows simple metadata structure for simple python application deployment. Important parameters are cluster_name labeling individual deployments and cluster.domain giving the deployment nodes domain part of the FQDN. /srv/salt/reclass/ |-- classes/ | |-- cluster/ | | `-- deployment/ | | |-- infra/ | | | `-- config.yml | | |-- python_app/ | | | |-- database.yml | | | `-- web.yml | | `-- init.yml | |-- system/ | | |-- python_app/ | | | `-- server/ | | | |-- [dev|prd].yml | | | `-- [single|cluster].yml | | |-- postgresql/ | | | `-- server/ | | | |-- cluster.yml | | | `-- single.yml | | |-- linux/ | | | `-- system/ | | | `-- init.yml | | `-- deployment2.yml | `-- service/ | |-- linux/ [formula metadata] | |-- python-app/ [formula metadata] | `-- openssh/ [formula metadata] `-- nodes/ `-- cfg.cluster.domain.yml You start with defining single node cfg.cluster.domain in nodes directory and that is core node pointing to your clus- ter.deploy.infra.config class. Content of the nodes/cfg.cluster.domain.yml file: classes: - cluster.deploy.infra.config parameters: (continues on next page) 2.1. Project Introduction 7 SaltStack-Formulas Documentation, Release master (continued from previous page) _param: reclass_data_revision: master linux: system: name: cfg01 domain: cluster.domain Contains pointer to class cluster.deploy.infra.config and some basic parameters. Content of the classes/cluster/deploy/infra/config.yml file: classes: - system.openssh.client - system.salt.master.git - system.salt.master.formula.git - system.reclass.storage.salt - cluster.cluster_name parameters: _param: salt_master_base_environment: dev reclass_data_repository: [email protected]:reclass-models/salt-model.git salt_master_environment_repository:"https://github.com/salt-formulas" reclass_data_revision: master reclass_config_master: ${_param:infra_config_deploy_address} single_address: ${_param:infra_config_address} reclass: storage: node: python_app01: name: app01 domain: ${_param:cluster_domain} classes: - cluster.${_param:cluster_name}.python_app.application params: salt_master_host: ${_param:reclass_config_master} single_address: ${_param:python_application_node01_single_address} database_address: ${_param:python_database_node01_single_address} python_dbs01: name: dbs01 domain: ${_param:cluster_domain} classes: - cluster.${_param:cluster_name}.python_app.database params: salt_master_host: ${_param:reclass_config_master} single_address: ${_param:python_database_node01_single_address} More about structure and layout of the metadata can be found in Metadata chapter. • Documentation Home • Project Introduction • Installation and Operations Manual • Development Documentation Home SaltStack-Formulas Project Introduction 8 Chapter 2. Contents SaltStack-Formulas Documentation, Release master Bootstrap Salt-Formulas infrastructure • TL;DR • Quick bootstrap – Bootstrap salt-master – Bootstrap salt-minion • Advanced usage – Additional
Recommended publications
  • Administració De Sistemes GNU Linux Mòdul4 Administració

    Administració De Sistemes GNU Linux Mòdul4 Administració

    Administració local Josep Jorba Esteve PID_00238577 GNUFDL • PID_00238577 Administració local Es garanteix el permís per a copiar, distribuir i modificar aquest document segons els termes de la GNU Free Documentation License, Version 1.3 o qualsevol altra de posterior publicada per la Free Software Foundation, sense seccions invariants ni textos de la oberta anterior o posterior. Podeu consultar els termes de la llicència a http://www.gnu.org/licenses/fdl-1.3.html. GNUFDL • PID_00238577 Administració local Índex Introducció.................................................................................................. 5 1. Eines bàsiques per a l'administrador........................................... 7 1.1. Eines gràfiques i línies de comandes .......................................... 8 1.2. Documents d'estàndards ............................................................. 10 1.3. Documentació del sistema en línia ............................................ 13 1.4. Eines de gestió de paquets .......................................................... 15 1.4.1. Paquets TGZ ................................................................... 16 1.4.2. Fedora/Red Hat: paquets RPM ....................................... 19 1.4.3. Debian: paquets DEB ..................................................... 24 1.4.4. Nous formats d'empaquetat: Snap i Flatpak .................. 28 1.5. Eines genèriques d'administració ................................................ 36 1.6. Altres eines .................................................................................
  • Storage Administration Guide Storage Administration Guide SUSE Linux Enterprise Server 12 SP4

    Storage Administration Guide Storage Administration Guide SUSE Linux Enterprise Server 12 SP4

    SUSE Linux Enterprise Server 12 SP4 Storage Administration Guide Storage Administration Guide SUSE Linux Enterprise Server 12 SP4 Provides information about how to manage storage devices on a SUSE Linux Enterprise Server. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xii 1 Available Documentation xii 2 Giving Feedback xiv 3 Documentation Conventions xiv 4 Product Life Cycle and Support xvi Support Statement for SUSE Linux Enterprise Server xvii • Technology Previews xviii I FILE SYSTEMS AND MOUNTING 1 1 Overview
  • Trusted Docker Containers and Trusted Vms in Openstack

    Trusted Docker Containers and Trusted Vms in Openstack

    Trusted Docker Containers and Trusted VMs in OpenStack Raghu Yeluri Abhishek Gupta Outline o Context: Docker Security – Top Customer Asks o Intel’s Focus: Trusted Docker Containers o Who Verifies Trust ? o Reference Architecture with OpenStack o Demo o Availability o Call to Action Docker Overview in a Slide.. Docker Hub Lightweight, open source engine for creating, deploying containers Provides work flow for running, building and containerizing apps. Separates apps from where they run.; Enables Micro-services; scale by composition. Underlying building blocks: Linux kernel's namespaces (isolation) + cgroups (resource control) + .. Components of Docker Docker Engine – Runtime for running, building Docker containers. Docker Repositories(Hub) - SaaS service for sharing/managing images Docker Images (layers) Images hold Apps. Shareable snapshot of software. Container is a running instance of image. Orchestration: OpenStack, Docker Swarm, Kubernetes, Mesos, Fleet, Project Docker Layers Atomic, Lattice… Docker Security – 5 key Customer Asks 1. How do you know that the Docker Host Integrity is there? o Do you trust the Docker daemon? o Do you trust the Docker host has booted with Integrity? 2. How do you verify Docker Container Integrity o Who wrote the Docker image? Do you trust the image? Did the right Image get launched? 3. Runtime Protection of Docker Engine & Enhanced Isolation o How can Intel help with runtime Integrity? 4. Enterprise Security Features – Compliance, Manageability, Identity authentication.. Etc. 5. OpenStack as a single Control Plane for Trusted VMs and Trusted Docker Containers.. Intel’s Focus: Enable Hardware-based Integrity Assurance for Docker Containers – Trusted Docker Containers Trusted Docker Containers – 3 focus areas o Launch Integrity of Docker Host o Runtime Integrity of Docker Host o Integrity of Docker Images Today’s Focus: Integrity of Docker Host, and how to use it in OpenStack.
  • Providing User Security Guarantees in Public Infrastructure Clouds

    Providing User Security Guarantees in Public Infrastructure Clouds

    1 Providing User Security Guarantees in Public Infrastructure Clouds Nicolae Paladi, Christian Gehrmann, and Antonis Michalas Abstract—The infrastructure cloud (IaaS) service model offers improved resource flexibility and availability, where tenants – insulated from the minutiae of hardware maintenance – rent computing resources to deploy and operate complex systems. Large-scale services running on IaaS platforms demonstrate the viability of this model; nevertheless, many organizations operating on sensitive data avoid migrating operations to IaaS platforms due to security concerns. In this paper, we describe a framework for data and operation security in IaaS, consisting of protocols for a trusted launch of virtual machines and domain-based storage protection. We continue with an extensive theoretical analysis with proofs about protocol resistance against attacks in the defined threat model. The protocols allow trust to be established by remotely attesting host platform configuration prior to launching guest virtual machines and ensure confidentiality of data in remote storage, with encryption keys maintained outside of the IaaS domain. Presented experimental results demonstrate the validity and efficiency of the proposed protocols. The framework prototype was implemented on a test bed operating a public electronic health record system, showing that the proposed protocols can be integrated into existing cloud environments. Index Terms—Security; Cloud Computing; Storage Protection; Trusted Computing F 1 INTRODUCTION host level. While support data encryption at rest is offered by several cloud providers and can be configured by tenants Cloud computing has progressed from a bold vision to mas- in their VM instances, functionality and migration capabil- sive deployments in various application domains. However, ities of such solutions are severely restricted.
  • USB Composite Gadget Using CONFIG-FS on Dra7xx Devices

    USB Composite Gadget Using CONFIG-FS on Dra7xx Devices

    Application Report SPRACB5–September 2017 USB Composite Gadget Using CONFIG-FS on DRA7xx Devices RaviB ABSTRACT This application note explains how to create a USB composite gadget, network control model (NCM) and abstract control model (ACM) from the user space using Linux® CONFIG-FS on the DRA7xx platform. Contents 1 Introduction ................................................................................................................... 2 2 USB Composite Gadget Using CONFIG-FS ............................................................................. 3 3 Creating Composite Gadget From User Space.......................................................................... 4 4 References ................................................................................................................... 8 List of Figures 1 Block Diagram of USB Composite Gadget............................................................................... 3 2 Selection of CONFIGFS Through menuconfig........................................................................... 4 3 Select USB Configuration Through menuconfig......................................................................... 4 4 Composite Gadget Configuration Items as Files and Directories ..................................................... 5 5 VID, PID, and Manufacturer String Configuration ....................................................................... 6 6 Kernel Logs Show Enumeration of USB Composite Gadget by Host ................................................ 6 7 Ping
  • Introduction Use Runit with Traditional Init (Sysvinit)

    Introduction Use Runit with Traditional Init (Sysvinit)

    2021/07/26 19:10 (UTC) 1/12 Runit Runit Introduction runit is a UNIX init scheme with service supervision. It is a cross-platform Unix init scheme with service supervision, a replacement for sysvinit, and other init schemes and supervision that are used with the traditional init. runit is compatible with djb's daemontools. In Unix-based computer operating systems, init (short for initialization) is the first process started during booting of the computer system. Init is a daemon process that continues running until the system is shut down. Slackware comes with its own legacy init (/sbin/init) from the sysvinit package, that used to be included in almost all other major Linux distributions. The init daemon (or its replacement) is characterised by Process ID 1 (PID 1). To read on the benefits of runit, see here: http://smarden.org/runit/benefits.html * Unless otherwise stated, all commands in this article are to be run by root. Use runit with traditional init (sysvinit) runit is not provided by Slackware, but a SlackBuild is maintained on https://slackbuilds.org/. It does not have any dependencies. As we do not want yet to replace init with runit, run the slackbuild with CONFIG=no: CONFIG=no ./runit.SlackBuild Then install the resulting package and proceed as follows: mkdir /etc/runit/ /service/ cp -a /usr/doc/runit-*/etc/2 /etc/runit/ /sbin/runsvdir-start & Starting via rc.local For a typical Slackware-stlyle service, you can edit /etc/rc.d/rc.local file if [ -x /sbin/runsvdir-start ]; then /sbin/runsvdir-start & fi and then edit write /etc/rc.d/rc.local_shutdown #!/bin/sh SlackDocs - https://docs.slackware.com/ Last update: 2020/05/06 08:08 (UTC) howtos:slackware_admin:runit https://docs.slackware.com/howtos:slackware_admin:runit RUNIT=x$( /sbin/pidof runsvdir ) if [ "$RUNIT" != x ]; then kill $RUNIT fi Then give rc.local_shutdown executive permission: chmod +x /etc/rc.d/rc.local_shutdown and reboot Starting via inittab (supervised) Remove the entries in /etc/rc.d/rc.local and /etc/rc.d/rc.local_shutdown described above.
  • Salt Documentation Release 2014.7.6

    Salt Documentation Release 2014.7.6

    Salt Documentation Release 2014.7.6 SaltStack, Inc. May 19, 2015 Contents 1 Introduction to Salt 1 1.1 e 30 second summary ........................................... 1 1.2 Simplicity ................................................... 1 1.3 Parallel execution ............................................... 1 1.4 Building on proven technology ....................................... 2 1.5 Python client interface ............................................ 2 1.6 Fast, flexible, scalable ............................................. 2 1.7 Open ...................................................... 2 1.8 Salt Community ................................................ 2 1.9 Mailing List .................................................. 2 1.10 IRC ....................................................... 3 1.11 Follow on Github ............................................... 3 1.12 Blogs ...................................................... 3 1.13 Example Salt States .............................................. 3 1.14 Follow on ohloh ................................................ 3 1.15 Other community links ............................................ 4 1.16 Hack the Source ................................................ 4 2 Installation 5 2.1 ick Install .................................................. 5 2.2 Platform-specific Installation Instructions ................................. 5 2.3 Dependencies ................................................. 26 2.4 Optional Dependencies ............................................ 27 2.5 Upgrading
  • NOVA: a Log-Structured File System for Hybrid Volatile/Non

    NOVA: a Log-Structured File System for Hybrid Volatile/Non

    NOVA: A Log-structured File System for Hybrid Volatile/Non-volatile Main Memories Jian Xu and Steven Swanson, University of California, San Diego https://www.usenix.org/conference/fast16/technical-sessions/presentation/xu This paper is included in the Proceedings of the 14th USENIX Conference on File and Storage Technologies (FAST ’16). February 22–25, 2016 • Santa Clara, CA, USA ISBN 978-1-931971-28-7 Open access to the Proceedings of the 14th USENIX Conference on File and Storage Technologies is sponsored by USENIX NOVA: A Log-structured File System for Hybrid Volatile/Non-volatile Main Memories Jian Xu Steven Swanson University of California, San Diego Abstract Hybrid DRAM/NVMM storage systems present a host of opportunities and challenges for system designers. These sys- Fast non-volatile memories (NVMs) will soon appear on tems need to minimize software overhead if they are to fully the processor memory bus alongside DRAM. The result- exploit NVMM’s high performance and efficiently support ing hybrid memory systems will provide software with sub- more flexible access patterns, and at the same time they must microsecond, high-bandwidth access to persistent data, but provide the strong consistency guarantees that applications managing, accessing, and maintaining consistency for data require and respect the limitations of emerging memories stored in NVM raises a host of challenges. Existing file sys- (e.g., limited program cycles). tems built for spinning or solid-state disks introduce software Conventional file systems are not suitable for hybrid mem- overheads that would obscure the performance that NVMs ory systems because they are built for the performance char- should provide, but proposed file systems for NVMs either in- acteristics of disks (spinning or solid state) and rely on disks’ cur similar overheads or fail to provide the strong consistency consistency guarantees (e.g., that sector updates are atomic) guarantees that applications require.
  • Firecracker: Lightweight Virtualization for Serverless Applications

    Firecracker: Lightweight Virtualization for Serverless Applications

    Firecracker: Lightweight Virtualization for Serverless Applications Alexandru Agache, Marc Brooker, Andreea Florescu, Alexandra Iordache, Anthony Liguori, Rolf Neugebauer, Phil Piwonka, and Diana-Maria Popa, Amazon Web Services https://www.usenix.org/conference/nsdi20/presentation/agache This paper is included in the Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’20) February 25–27, 2020 • Santa Clara, CA, USA 978-1-939133-13-7 Open access to the Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’20) is sponsored by Firecracker: Lightweight Virtualization for Serverless Applications Alexandru Agache Marc Brooker Andreea Florescu Amazon Web Services Amazon Web Services Amazon Web Services Alexandra Iordache Anthony Liguori Rolf Neugebauer Amazon Web Services Amazon Web Services Amazon Web Services Phil Piwonka Diana-Maria Popa Amazon Web Services Amazon Web Services Abstract vantage over traditional server provisioning processes: mul- titenancy allows servers to be shared across a large num- Serverless containers and functions are widely used for de- ber of workloads, and the ability to provision new func- ploying and managing software in the cloud. Their popularity tions and containers in milliseconds allows capacity to be is due to reduced cost of operations, improved utilization of switched between workloads quickly as demand changes. hardware, and faster scaling than traditional deployment meth- Serverless is also attracting the attention of the research com- ods. The economics and scale of serverless applications de- munity [21,26,27,44,47], including work on scaling out video mand that workloads from multiple customers run on the same encoding [13], linear algebra [20, 53] and parallel compila- hardware with minimal overhead, while preserving strong se- tion [12].
  • Oracle® Linux 7 Managing File Systems

    Oracle® Linux 7 Managing File Systems

    Oracle® Linux 7 Managing File Systems F32760-07 August 2021 Oracle Legal Notices Copyright © 2020, 2021, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
  • Unionfs: User- and Community-Oriented Development of a Unification File System

    Unionfs: User- and Community-Oriented Development of a Unification File System

    Unionfs: User- and Community-Oriented Development of a Unification File System David Quigley, Josef Sipek, Charles P. Wright, and Erez Zadok Stony Brook University {dquigley,jsipek,cwright,ezk}@cs.sunysb.edu Abstract If a file exists in multiple branches, the user sees only the copy in the higher-priority branch. Unionfs allows some branches to be read-only, Unionfs is a stackable file system that virtually but as long as the highest-priority branch is merges a set of directories (called branches) read-write, Unionfs uses copy-on-write seman- into a single logical view. Each branch is as- tics to provide an illusion that all branches are signed a priority and may be either read-only writable. This feature allows Live-CD develop- or read-write. When the highest priority branch ers to give their users a writable system based is writable, Unionfs provides copy-on-write se- on read-only media. mantics for read-only branches. These copy- on-write semantics have lead to widespread There are many uses for namespace unifica- use of Unionfs by LiveCD projects including tion. The two most common uses are Live- Knoppix and SLAX. In this paper we describe CDs and diskless/NFS-root clients. On Live- our experiences distributing and maintaining CDs, by definition, the data is stored on a read- an out-of-kernel module since November 2004. only medium. However, it is very convenient As of March 2006 Unionfs has been down- for users to be able to modify the data. Uni- loaded by over 6,700 unique users and is used fying the read-only CD with a writable RAM by over two dozen other projects.
  • ODROID-HC2: 3.5” High Powered Storage  February 1, 2018

    ODROID-HC2: 3.5” High Powered Storage  February 1, 2018

    ODROID WiFi Access Point: Share Files Via Samba February 1, 2018 How to setup an ODROID with a WiFi access point so that an ODROID’s hard drive can be accessed and modied from another computer. This is primarily aimed at allowing access to images, videos, and log les on the ODROID. ODROID-HC2: 3.5” High powered storage February 1, 2018 The ODROID-HC2 is an aordable mini PC and perfect solution for a network attached storage (NAS) server. This device home cloud-server capabilities centralizes data and enables users to share and stream multimedia les to phones, tablets, and other devices across a network. It is an ideal tool for many use Using SquashFS As A Read-Only Root File System February 1, 2018 This guide describes the usage of SquashFS PiFace: Control and Display 2 February 1, 2018 For those who have the PiFace Control and Display 2, and want to make it compatible with the ODROID-C2 Android Gaming: Data Wing, Space Frontier, and Retro Shooting – Pixel Space Shooter February 1, 2018 Variations on a theme! Race, blast into space, and blast things into pieces that are racing towards us. The fun doesn’t need to stop when you take a break from your projects. Our monthly pick on Android games. Linux Gaming: Saturn Games – Part 1 February 1, 2018 I think it’s time we go into a bit more detail about Sega Saturn for the ODROID-XU3/XU4 Gaming Console: Running Your Favorite Games On An ODROID-C2 Using Android February 1, 2018 I built a gaming console using an ODROID-C2 running Android 6 Controller Area Network (CAN) Bus: Implementation