DOCSLIB.ORG

Gestion De Services Sous Unix

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Gestion De Services Sous Unix Gestion de services sous Unix Baptiste Daroussin [email protected] [email protected] sysadmin #6 Paris 19 Février 2016 Disclaimer sysadmin#6 Gestion de services sous Unix 2 of 16 L’arlésienne supervisor daemontools procd OpenRC DEMONS Runit Epoch ninit finitrcNG sinit minitsystemdinitng rc svc perp eINIT SMF SysVinit nosh SystemXVI upstart launchd monit Shepherd relaunchd sparkrc watchmancircus sysadmin#6 Gestion de services sous Unix 3 of 16 I I’m your father(c)(tm) I laisse la main a d’autres pour la gestion des services... presque I /etc/inittab I /etc/ttys I Généralement des scripts shell I SysVinit I rcNG I rc Il était une fois init(8) I petit mais costaud sysadmin#6 Gestion de services sous Unix 4 of 16 I laisse la main a d’autres pour la gestion des services... presque I /etc/inittab I /etc/ttys I Généralement des scripts shell I SysVinit I rcNG I rc Il était une fois init(8) I petit mais costaud I I’m your father(c)(tm) sysadmin#6 Gestion de services sous Unix 4 of 16 presque I /etc/inittab I /etc/ttys I Généralement des scripts shell I SysVinit I rcNG I rc Il était une fois init(8) I petit mais costaud I I’m your father(c)(tm) I laisse la main a d’autres pour la gestion des services... sysadmin#6 Gestion de services sous Unix 4 of 16 I /etc/inittab I /etc/ttys I Généralement des scripts shell I SysVinit I rcNG I rc Il était une fois init(8) I petit mais costaud I I’m your father(c)(tm) I laisse la main a d’autres pour la gestion des services... presque sysadmin#6 Gestion de services sous Unix 4 of 16 I Généralement des scripts shell I SysVinit I rcNG I rc Il était une fois init(8) I petit mais costaud I I’m your father(c)(tm) I laisse la main a d’autres pour la gestion des services... presque I /etc/inittab I /etc/ttys sysadmin#6 Gestion de services sous Unix 4 of 16 Il était une fois init(8) I petit mais costaud I I’m your father(c)(tm) I laisse la main a d’autres pour la gestion des services... presque I /etc/inittab I /etc/ttys I Généralement des scripts shell I SysVinit I rcNG I rc sysadmin#6 Gestion de services sous Unix 4 of 16 I trop naïf I framework complexes I cohérence compliquée I gestion de ressource complexe I peu réactif Alors pourquoi tout ce bordel? sysadmin#6 Gestion de services sous Unix 5 of 16 I framework complexes I cohérence compliquée I gestion de ressource complexe I peu réactif Alors pourquoi tout ce bordel? I trop naïf sysadmin#6 Gestion de services sous Unix 5 of 16 I cohérence compliquée I gestion de ressource complexe I peu réactif Alors pourquoi tout ce bordel? I trop naïf I framework complexes sysadmin#6 Gestion de services sous Unix 5 of 16 I gestion de ressource complexe I peu réactif Alors pourquoi tout ce bordel? I trop naïf I framework complexes I cohérence compliquée sysadmin#6 Gestion de services sous Unix 5 of 16 I peu réactif Alors pourquoi tout ce bordel? I trop naïf I framework complexes I cohérence compliquée I gestion de ressource complexe sysadmin#6 Gestion de services sous Unix 5 of 16 Alors pourquoi tout ce bordel? I trop naïf I framework complexes I cohérence compliquée I gestion de ressource complexe I peu réactif sysadmin#6 Gestion de services sous Unix 5 of 16 I ne peut superviser qu’un process simple (via son pid) I perdu si double fork I interactions limitées I gestion de dépendance faible Trop naïf sysadmin#6 Gestion de services sous Unix 6 of 16 I perdu si double fork I interactions limitées I gestion de dépendance faible Trop naïf I ne peut superviser qu’un process simple (via son pid) sysadmin#6 Gestion de services sous Unix 6 of 16 I interactions limitées I gestion de dépendance faible Trop naïf I ne peut superviser qu’un process simple (via son pid) I perdu si double fork sysadmin#6 Gestion de services sous Unix 6 of 16 I gestion de dépendance faible Trop naïf I ne peut superviser qu’un process simple (via son pid) I perdu si double fork I interactions limitées sysadmin#6 Gestion de services sous Unix 6 of 16 Trop naïf I ne peut superviser qu’un process simple (via son pid) I perdu si double fork I interactions limitées I gestion de dépendance faible sysadmin#6 Gestion de services sous Unix 6 of 16 I généralement en shell I complexe à isoler (cf commande service(8)) I complexe à garder une cohérence entre les scripts d’init I complexe d’intégrer les systèmes de gestion de ressources I souvent inefficace (performances) I pas de mécanismes de surveillance de processus I peu de contrôle sur les processus (double fork) I fiabilité aléatoire du statut Framework complexes sysadmin#6 Gestion de services sous Unix 7 of 16 I complexe à isoler (cf commande service(8)) I complexe à garder une cohérence entre les scripts d’init I complexe d’intégrer les systèmes de gestion de ressources I souvent inefficace (performances) I pas de mécanismes de surveillance de processus I peu de contrôle sur les processus (double fork) I fiabilité aléatoire du statut Framework complexes I généralement en shell sysadmin#6 Gestion de services sous Unix 7 of 16 I complexe à garder une cohérence entre les scripts d’init I complexe d’intégrer les systèmes de gestion de ressources I souvent inefficace (performances) I pas de mécanismes de surveillance de processus I peu de contrôle sur les processus (double fork) I fiabilité aléatoire du statut Framework complexes I généralement en shell I complexe à isoler (cf commande service(8)) sysadmin#6 Gestion de services sous Unix 7 of 16 I complexe d’intégrer les systèmes de gestion de ressources I souvent inefficace (performances) I pas de mécanismes de surveillance de processus I peu de contrôle sur les processus (double fork) I fiabilité aléatoire du statut Framework complexes I généralement en shell I complexe à isoler (cf commande service(8)) I complexe à garder une cohérence entre les scripts d’init sysadmin#6 Gestion de services sous Unix 7 of 16 I souvent inefficace (performances) I pas de mécanismes de surveillance de processus I peu de contrôle sur les processus (double fork) I fiabilité aléatoire du statut Framework complexes I généralement en shell I complexe à isoler (cf commande service(8)) I complexe à garder une cohérence entre les scripts d’init I complexe d’intégrer les systèmes de gestion de ressources sysadmin#6 Gestion de services sous Unix 7 of 16 I pas de mécanismes de surveillance de processus I peu de contrôle sur les processus (double fork) I fiabilité aléatoire du statut Framework complexes I généralement en shell I complexe à isoler (cf commande service(8)) I complexe à garder une cohérence entre les scripts d’init I complexe d’intégrer les systèmes de gestion de ressources I souvent inefficace (performances) sysadmin#6 Gestion de services sous Unix 7 of 16 I peu de contrôle sur les processus (double fork) I fiabilité aléatoire du statut Framework complexes I généralement en shell I complexe à isoler (cf commande service(8)) I complexe à garder une cohérence entre les scripts d’init I complexe d’intégrer les systèmes de gestion de ressources I souvent inefficace (performances) I pas de mécanismes de surveillance de processus sysadmin#6 Gestion de services sous Unix 7 of 16 I fiabilité aléatoire du statut Framework complexes I généralement en shell I complexe à isoler (cf commande service(8)) I complexe à garder une cohérence entre les scripts d’init I complexe d’intégrer les systèmes de gestion de ressources I souvent inefficace (performances) I pas de mécanismes de surveillance de processus I peu de contrôle sur les processus (double fork) sysadmin#6 Gestion de services sous Unix 7 of 16 Framework complexes I généralement en shell I complexe à isoler (cf commande service(8)) I complexe à garder une cohérence entre les scripts d’init I complexe d’intégrer les systèmes de gestion de ressources I souvent inefficace (performances) I pas de mécanismes de surveillance de processus I peu de contrôle sur les processus (double fork) I fiabilité aléatoire du statut sysadmin#6 Gestion de services sous Unix 7 of 16 I gestion événementielle forcément externe (cron, udev/devd, inetd) I duplication de la gestion des services I incohérence dans la gestion des services I gestion événementielle souvent peu réactive: latence entre l’arrivée de l’évènement et l’action I fault management absent Réactivité sysadmin#6 Gestion de services sous Unix 8 of 16 I duplication de la gestion des services I incohérence dans la gestion des services I gestion événementielle souvent peu réactive: latence entre l’arrivée de l’évènement et l’action I fault management absent Réactivité I gestion événementielle forcément externe (cron, udev/devd, inetd) sysadmin#6 Gestion de services sous Unix 8 of 16 I gestion événementielle souvent peu réactive: latence entre l’arrivée de l’évènement et l’action I fault management absent Réactivité I gestion événementielle forcément externe (cron, udev/devd, inetd) I duplication de la gestion des services I incohérence dans la gestion des services sysadmin#6 Gestion de services sous Unix 8 of 16 I fault management absent Réactivité I gestion événementielle forcément externe (cron, udev/devd, inetd) I duplication de la gestion des services I incohérence dans la gestion des services I gestion événementielle souvent peu réactive: latence entre l’arrivée de l’évènement et l’action sysadmin#6 Gestion de services sous Unix 8 of 16 Réactivité I gestion événementielle forcément externe (cron, udev/devd, inetd) I duplication de la gestion des services I incohérence dans la gestion des services I gestion événementielle souvent peu réactive: latence entre l’arrivée de l’évènement et l’action I fault management absent sysadmin#6 Gestion de services sous Unix 8 of
Load more

Recommended publications
  • Alpine Linux: Minimalistická Distribuce Nejen Na Server
    Alpine Linux: minimalistická distribuce nejen na server Petr Krčmář 5. března 2017 Uvedené dílo (s výjimkou obrázků) podléhá licenci Creative Commons Uveďte autora 3.0 Česko. Petr Krčmář (Root.cz, vpsFree.cz) Alpine Linux: minimalistická distribuce nejen na server 5. března 2017 1 / 19 Petr Krčmář (Root.cz, vpsFree.cz) Alpine Linux: minimalistická distribuce nejen na server 5. března 2017 2 / 19 Prezentace už teď na webu https://www.petrkrcmar.cz Petr Krčmář (Root.cz, vpsFree.cz) Alpine Linux: minimalistická distribuce nejen na server 5. března 2017 3 / 19 Historie Alpine první verze 2006 původně jako fork LEAF (Linux Embedded Appliance Framework) to je zase fork LRP (Linux Router Project) = disketové distribuce vývojáři ale chtěli jít za hranici disket zůstala jednoduchost a přehlednost umožnilo to nasazení mimo jednoduché firewally dnes plnohodnotná distribuce stále umí běžet z RAM nezávislá, nekomerční Petr Krčmář (Root.cz, vpsFree.cz) Alpine Linux: minimalistická distribuce nejen na server 5. března 2017 4 / 19 K čemu se hodí? velká plnohodnotná distribuce embedded zařízení (síťové prvky) firewally routery ústředny VoIP servery a kontejnery ale i na desktop (Xfce, Gnome) Petr Krčmář (Root.cz, vpsFree.cz) Alpine Linux: minimalistická distribuce nejen na server 5. března 2017 5 / 19 Motto Small. Simple. Secure. Petr Krčmář (Root.cz, vpsFree.cz) Alpine Linux: minimalistická distribuce nejen na server 5. března 2017 6 / 19 Small. instalace v kontejneru jen 8 MB, 260 souborů 16 balíčků, jen 6 z jiných projektů instalace do virtuálu 53 MB, 1222 souborů 26 balíčků plná instalace na železo 302 MB, 4686 souborů 27 balíčků hodně jaderných modulů Petr Krčmář (Root.cz, vpsFree.cz) Alpine Linux: minimalistická distribuce nejen na server 5.
    [Show full text]
  • 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.
    [Show full text]
  • Systemd – Easy As 1, 2, 3
    Systemd – Easy as 1, 2, 3 Ben Breard, RHCA Solutions Architect, Red Hat [email protected] Agenda ● Systemd functionality ● Coming to terms ● Learning the basics ● More advanced topics ● Learning the journal ● Available resources 2 Systemd is more than a SysVinit replacement 3 Systemd is a system and service manager 4 Systemd Overview ● Controls “units” rather than just daemons ● Handles dependency between units. ● Tracks processes with service information ● Services are owned by a cgroup. ● Simple to configure “SLAs” based on CPU, Memory, and IO. ● Properly kill daemons ● Minimal boot times ● Debuggability – no early boot messages are lost ● Easy to learn and backwards compatible. 5 Closer look at Units 6 Systemd - Units ● Naming convention is: name.type ● httpd.service, sshd.socket, or dev-hugepages.mount ● Service – Describe a daemon's type, execution, environment, and how it's monitored. ● Socket – Endpoint for interprocess communication. File, network, or Unix sockets. ● Target – Logical grouping of units. Replacement for runlevels. ● Device – Automatically created by the kernel. Can be provided to services as dependents. ● Mounts, automounts, swap – Monitor the mounting/unmounting of file systems. 7 Systemd – Units Continued ● Snapshots – save the state of units – useful for testing ● Timers – Timer-based activation ● Paths – Uses inotify to monitor a path ● Slices – For resource management. ● system.slice – services started by systemd ● user.slice – user processes ● machine.slice – VMs or containers registered with systemd 8 Systemd – Dependency Resolution ● Example: ● Wait for block device ● Check file system for device ● Mount file system ● nfs-lock.service: ● Requires=rpcbind.service network.target ● After=network.target named.service rpcbind.service ● Before=remote-fs-pre.target 9 That's all great .......but 10 Replace Init scripts!? Are you crazy?! 11 We're not crazy, I promise ● SysVinit had a good run, but leaves a lot to be desired.
    [Show full text]
  • Cisco Virtualized Infrastructure Manager Installation Guide, 2.4.9
    Cisco Virtualized Infrastructure Manager Installation Guide, 2.4.9 First Published: 2019-01-09 Last Modified: 2019-05-20 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883 THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
    [Show full text]
  • Introduction to Gentoo Linux
    Introduction to Gentoo Linux Ulrich Müller Developer and Council member, Gentoo Linux <[email protected]> Institut für Kernphysik, Universität Mainz <[email protected]> Seminar “Learn Linux the hard way”, Mainz, 2012-10-23 Ulrich Müller (Gentoo Linux) Introduction to Gentoo Linux Mainz 2012 1 / 35 Table of contents 1 History 2 Why Gentoo? 3 Compile everything? – Differences to other distros 4 Gentoo features 5 Gentoo as metadistribution 6 Organisation of the Gentoo project 7 Example of developer’s work Ulrich Müller (Gentoo Linux) Introduction to Gentoo Linux Mainz 2012 2 / 35 /"dZEntu:/ Pygoscelis papua Fastest swimming penguin Source: Wikimedia Commons License: CC-BY-SA-2.5, Attribution: Stan Shebs Ulrich Müller (Gentoo Linux) Introduction to Gentoo Linux Mainz 2012 3 / 35 How I came to Gentoo UNIX since 1987 (V7 on Perkin-Elmer 3220, later Ultrix, OSF/1, etc.) GNU/Linux since 1995 (Slackware, then S.u.S.E.) Switched to Gentoo in January 2004 Developer since April 2007 Council Mai 2009–June 2010 and since July 2011 Projects: GNU Emacs, eselect, PMS, QA Ulrich Müller (Gentoo Linux) Introduction to Gentoo Linux Mainz 2012 4 / 35 Overview Based on GNU/Linux, FreeBSD, etc. Source-based metadistribution Can be optimised and customised for any purpose Extremely configurable, portable, easy-to-maintain Active all-volunteer developer community Social contract GPL, LGPL, or other OSI-approved licenses Will never depend on non-free software Is and will always remain Free Software Commitment to giving back to the FLOSS community, e.g. submit bugs
    [Show full text]
  • Unit V Algorithm for Booting the UNIX System
    Unit V Algorithm for booting the UNIX system : As we’ve noted, the boot process begins when the instructions stored in the computer’s permanent, nonvolatile memory (referred to colloquially as the BIOS, ROM,NVRAM, and so on) are executed. This storage location for the initial boot instructions is generically referred to as firmware (in contrast to “software,” but reflecting the fact that the instructions constitute a program[2]). These instructions are executed automatically when the power is turned on or the system is reset, although the exact sequence of events may vary according to the values of stored parameters.[3] The firmware instructions may also begin executing in response to a command entered on the system console (as we’ll see in a bit). However they are initiated, these instructions are used to locate and start up the system’s boot program , which in turn starts the Unix operating system. The boot program is stored in a standard location on a bootable device. For a normal boot from disk, for example, the boot program might be located in block 0 of the root disk or, less commonly, in a special partition on the root disk. In the same way, the boot program may be the second file on a bootable tape or in a designated location on a remote file server in the case of a network boot of a diskless workstation. There is usually more than one bootable device on a system. The firmware program may include logic for selecting the device to boot from, often in the form of a list of potential devices to examine.
    [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]
  • Slides for the S6 Lightning Talk
    The s6 supervision suite Laurent Bercot, 2017 What is an init system ? - “init” is vague terminology. “init wars” happened because nobody had a clear vision on what an init system even is or should be. - The 4 elements of an init system: /sbin/init, pid 1, process supervision, service management. - Not necessarily in the same process. Definition: process supervision A long-lived process (daemon) is supervised when it’s spawned by the supervision tree, a set of stable, long-lived processes started at boot time by pid 1. (Often just pid 1.) Supervision is a good pattern: the service is stable and launched in a reproducible env. Supervision only applies to daemons. Service management: definition - Boot time: bring all services up - Shutdown time: bring all services down - More generally: change services’ states Services can be oneshots (short-lived programs with side effects) or longruns (daemons). They have dependencies, which the service manager should enforce. What features do “init”s offer ? - Integrated init systems (systemd, launchd, upstart): “the big guys”. All four elements in one package, plus out-of-scope stuff. - sysvinit, BSD init: /sbin/init, pid 1, supervision (/etc/inittab, /etc/gettys). Service manager not included: sysv-rc, /etc/rc - OpenRC: service manager. - Epoch: similar to sysvinit + sysv-rc The “daemontools family” - /etc/inittab supervision is impractical; nobody uses it for anything else than gettys. - daemontools (DJB, 1998): the first project offering flexible process supervision. Realistic to supervise all daemons with it. - daemontools-encore, runit, perp, s6: supervision suites. - nosh: suite of tools similar to s6, in C++ Supervision suites are not enough - Only ¼ of an init system.
    [Show full text]
  • Continuous Integration with Jenkins
    Automated Deployment … of Debian & Ubuntu Michael Prokop About Me Debian Developer Project lead of Grml.org ounder of Grml-Forensic.org #nvolved in A#$ initramf"-tools$ etc. Member in Debian orensic Team Author of &ook $$Open Source Projektmanagement) #T *on"ultant Disclaimer" Deployment focuses on Linux (everal tools mentioned$ but there exist even more :. We'll cover some sections in more detail than others %here's no one-size-fits-all solution – identify what works for you Sy"tems Management Provisioning 4 Documentation &oot"trapping #nfrastructure 'rche"tration 4 Development Dev'ps Automation 6isualization/Trends *onfiguration 4Metric" + Logs Management Monitoring + *loud Service Updates Deployment Systems Management Remote Acce"" ipmi, HP i+'$ IBM RSA,... irm3are Management 9Vendor Tools Provisioning / Bootstrapping :ully) A(utomatic) I(n"tallation) Debian, Ubuntu$ Cent'( + Scientific +inu, http://fai-project.org/ ;uju Ubuntu <Charms= https-44juju.ubuntu.com/ grml-debootstrap netscript=http://example.org/net"cript.sh http-44grml.org4 d-i preseeding auto url>http-44debian.org/releases4\ "queeze/example-preseed.txt http-443iki.debian.org/DebianInstaller/Preseed Kickstart Cobbler Foreman AutoYa(%$ openQRM, (pace3alk,... Orche"tration / Automation Fabric (Python) % cat fabfile.py from fabric.api import run def host_type(): run('uname -s') % fab -H host1, host2,host3 host_type Capistrano (Ruby) % cat Capfile role :hosts, "host1", "host2", "host3" task :host_type, :roles => :hosts do run "uname -s" end % cap host_type 7undeck apt-dater % cat .config/apt-dater/hosts.conf [example.org] [email protected];mika@ mail.example.org;... *ontrolTier, Func$ MCollective$... *luster((8$ dsh, TakTuk,... *obbler$ Foreman$ openQRM, Spacewalk,... *onfiguration Management Puppet Environment" :production4"taging/development.
    [Show full text]
  • Power State Management in Automotive Linux
    Power State Management in Automotive Linux Table of Contents Terminology As automotive, consumer electronics, and embedded Executive Summary ............................................................1 software and hardware engineering intersect, technical Vehicle Power States and Device Energy traditions and vocabulary for in-car systems design begin Management ......................................................................1 to overlap. The following terms are defined for use in this Key Linux/Open Source Software Technologies document. for Automotive ...................................................................2 Power state management: Automakers and their supply CAN and MOST Drivers and Protocols ..........................2 chains use power management to describe the state of D-Bus ..............................................................................3 vehicles and in-vehicle systems relative to their policies for and use of electric power flowing from a vehicle’s Energy Management ......................................................3 alternator and battery. To minimize confusion between Initng: Next-Generation Init System ..............................3 familiar automotive terms and current embedded and System Health Monitoring – Monit ................................4 mobile terms, in this document power state management Conclusion ..........................................................................4 is used to describe the software infrastructure to support vehicle power states and transitions. Energy
    [Show full text]
  • 27Th Large Installation System Administration Conference (LISA '13)
    conference proceedings Proceedings of the 27th Large Installation System Administration Conference 27th Large Installation System Administration Conference (LISA ’13) Washington, D.C., USA November 3–8, 2013 Washington, D.C., USA November 3–8, 2013 Sponsored by In cooperation with LOPSA Thanks to Our LISA ’13 Sponsors Thanks to Our USENIX and LISA SIG Supporters Gold Sponsors USENIX Patrons Google InfoSys Microsoft Research NetApp VMware USENIX Benefactors Akamai EMC Hewlett-Packard Linux Journal Linux Pro Magazine Puppet Labs Silver Sponsors USENIX and LISA SIG Partners Cambridge Computer Google USENIX Partners Bronze Sponsors Meraki Nutanix Media Sponsors and Industry Partners ACM Queue IEEE Security & Privacy LXer ADMIN IEEE Software No Starch Press CiSE InfoSec News O’Reilly Media Computer IT/Dev Connections Open Source Data Center Conference Distributed Management Task Force IT Professional (OSDC) (DMTF) Linux Foundation Server Fault Free Software Magazine Linux Journal The Data Center Journal HPCwire Linux Pro Magazine Userfriendly.org IEEE Pervasive © 2013 by The USENIX Association All Rights Reserved This volume is published as a collective work. Rights to individual papers remain with the author or the author’s employer. Permission is granted for the noncommercial reproduction of the complete work for educational or research purposes. Permission is granted to print, primarily for one person’s exclusive use, a single copy of these Proceedings. USENIX acknowledges all trademarks herein. ISBN 978-1-931971-05-8 USENIX Association Proceedings of the 27th Large Installation System Administration Conference November 3–8, 2013 Washington, D.C. Conference Organizers Program Co-Chairs David Nalley, Apache Cloudstack Narayan Desai, Argonne National Laboratory Adele Shakal, Metacloud, Inc.
    [Show full text]
  • Your Init; Your Choice
    Your Computer; Your Init; Your Choice By Steve Litt Version 20150108_1348 Copyright © 2015 by Steve Litt Creative Commons Attribution-NoDerivatives 4.0 International License http://creativecommons.org/licenses/by-nd/4.0/legalcode Available online at http://www.troubleshooters.com/linux/presentations/golug_inits/golug_inits.pdf NO WARRANTY, use at your own risk. Slide 1 of 26 Your Computer; Your Init; Your Choice Steve Litt System Overview ● Kernel runs one program, init. ● Everything else run directly or indirectly by init. Slide 2 of 26 Your Computer; Your Init; Your Choice Steve Litt Many Different Init Systems ● Epoch ● nosh ● OpenRC ● perp ● RichFelker ● runit ● s6 ● systemd ● sysvinit ● Upstart ● uselessd ● Many more ● There's an init for every situation ● You can make your own Slide 3 of 26 Your Computer; Your Init; Your Choice Steve Litt Full vs Partial ● Kernel->full-init at PID1->daemons – Systemd, sysvinit, runit, Epoch, Upstart, etc. ● Kernel->PID1->partial-init->daemons – OpenRC, daemontools, damontools-encore, etc. Slide 4 of 26 Your Computer; Your Init; Your Choice Steve Litt Many Features ● Socket Activation ● Parallel starting ● Event controlled ● Sequential starting ● Daemontools-like ● Numeric ordering ● Simplicity ● Dependency ordering ● Descriptive config ● Work with sysvinit scripts ● Script config ● OS toolkit ● Forget features ● Look for benefits that fit your priorities and situation Slide 5 of 26 Your Computer; Your Init; Your Choice Steve Litt Many Routes to Benefits ● Within and outside of init ● With or without sockets ● With or without packaging ● Cutting edge or oldschool Slide 6 of 26 Your Computer; Your Init; Your Choice Steve Litt Bogus Characterizations ● ___ is a toy. – What does that even mean? ● ___ is not ready for prime time.
    [Show full text]