+ All Categories
Home > Documents > Systemd evolution revolution_regression

Systemd evolution revolution_regression

Date post: 10-Jun-2015
Category:
Upload: susant-sahani
View: 182 times
Download: 3 times
Share this document with a friend
Popular Tags:
18
Normation – CC-BY-SA normation.com systemd: Evolution, systemd: Evolution, Revolution or Decline ? Revolution or Decline ? ___________________________ ___________________________ “Huh? What's this systemd thingie doing “Huh? What's this systemd thingie doing as PID 1 ?” as PID 1 ?” Matthieu CERDA
Transcript
Page 1: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com

systemd: Evolution, systemd: Evolution, Revolution or Decline ?Revolution or Decline ?

______________________________________________________

“Huh? What's this systemd thingie doing “Huh? What's this systemd thingie doing as PID 1 ?”as PID 1 ?”

Matthieu CERDA

Page 2: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 2

Who are you ?

Name Matthieu CERDA

Email : [email protected]

Web site : http://www.normation.com

Twitter : @Kegeruneku

Job System engineer at Normation

CFEngine Enthusiast, power user and trainer

Rudder Integrator, packager

Infrastructure Team member

Page 3: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 3

What are we going to talk about

Systemd (but not only)

Page 4: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 4

What are we going to talk about

● The current situation of open init systems

● What is systemd?

● What can we do with it?

● Why all this controversy about it?

Page 5: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 5

Today's major open init systems (1/2)

● SysVinit / BSDinit: Historical, shell script based simple init systems, using LSB extensions on GNU/Linux and dependency tags on BSD to add dependencies.

● Upstart: Ubuntu's init flavour, uses specific configuration files (“jobs”) to manage services.

● OpenRC: Gentoo's init flavour, enhanced SysVinit version with more powerful service configuration / dependency handling.

Page 6: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 6

Today's major open init systems (2/2)

● SMF: Solaris init system, using XML + shell scripts to define how a service is to be managed.

● launchd, uses plist (xml/binary xml) files to define how a service is to be managed.

● *src, runit, daemon-tools, epoch, ...

Page 7: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 7

Why so many reimplementations ?

● Performance: init used to work in a serialized fashion, one script after the other. Long / hung scripts = slow / hung boot.

● Definition: No dependency definition, restart behaviour, ...)

● Security: Every process is awarded full root privileges by default and have to handle privilege dropping by itself.

● Ego: “Mine is bigger.”

Page 8: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 8

systemd ID card

● Created / Maintained by Lennart Poettering and Kay Sievers

● Drop-in replacement for SysVinit, “unit” based.

● GNU/Linux specific

http://www.freedesktop.org/wiki/Software/systemd/

Page 9: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 9

systemd goals

● Replace SysVinit, D-Bus and udev with enhanced features

● Completely separate the system and the applications

● Provide unified system components

● Enable the use of an “appliance” type of operating system

Page 10: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 10

Service management capabilities

● Uses systemd “units”

● Provides:

● A possibility to make sure a service is always started

● A possibility to restrict a process to a specific Cgroup

● Native Socket / D-Bus activation

Page 11: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 11

Service management capabilities

Example: OpenSSH unit (Debian)

[Unit]Description=OpenBSD Secure Shell serverAfter=network.target auditd.serviceConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]EnvironmentFile=-/etc/default/sshExecStart=/usr/sbin/sshd -D $SSHD_OPTSExecReload=/bin/kill -HUP $MAINPIDKillMode=processRestart=on-failure

[Install]WantedBy=multi-user.targetAlias=sshd.service

Page 12: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 12

Socket activation capabilities

Example: CUPS socket unit (Debian)

[Unit]Description=CUPS Printing Service Sockets

[Socket]ListenStream=/var/run/cups/cups.sockBindIPv6Only=ipv6-only

[Install]WantedBy=sockets.target

This unit will start the service provided by the “cups” unit if someone tries to access /var/run/cups/cups.sock

Page 13: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 13

Process isolation

● One may want a process to be started with an isolated environment for security reasons

● systemd provides several ways to run a process in a restricted environment:

● Traditionnal chroots, using the “RootDirectory” unit specification

● Namespace restrictions, to forbid some operations to the service (Example: InaccessibleDirectories to forbid access to a directory)

● Containerization: Using a lightweight containerization approach

Page 14: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 14

systemd containers

● It's like a limited LXC, way easier to use.

● One example is worth thousand words:● Spawn a shell inside a Debian testing installation

● Boot an ArchLinux OS inside a container

● Reboot your own root inside a container (with btrfs or ZFS)

# debootstrap --arch=amd64 testing ~/debian/# systemd-nspawn -D ~/debian/

# pacstrap -c -d ~/arch/ base# systemd-nspawn -bD ~/arch/

# btrfs subvolume snapshot / /.tmp# systemd-nspawn --private-network -D /.tmp -b

Page 15: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 15

systemd in a Cloud / Virtualized environment

● Systemd tends to become a standard in those kind of environments

● Provides interesting abstraction of processes

● systemd-nspawn is a great ally for testing/continuous integration environments

● Docker + systemd + etcd = CoreOS

● http://coreos.com

● Clustered GNU/Linux based Docker appliance serving OS

Page 16: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 16

Controversy (1/2)

● Monopoly

● GNU/Linux centrism

● Code complicated and bloated

● Too many services under the same management

● GNOME relationship

Page 17: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 17

Controversy (2/2)

● Public communication is... rough.

● Broken transition from SysVinit

● Forced adoption by absorbing essential services (udev)

● Inconsistent utility syntax

Page 18: Systemd evolution revolution_regression

Normation – CC-BY-SAnormation.com 18

Questions ? :)Questions ? :)


Recommended