Snaps on open suse
Download as ODP, PDF1 like568 views
The document provides an overview of snaps and snapd: - Snaps are packages that provide application sandboxing and confinement using interfaces and security policies. They work across distributions and allow automatic updates. - Snapcraft is used to build snaps by defining parts and plugins in a yaml file. Snaps are mounted at runtime rather than unpacked. - Snapd is the daemon that installs, removes, and updates snaps. It manages security interfaces and confinement policies between snaps. - The store publishes snaps to channels of different risk levels. Snapd installs the revisions specified by the store for each channel.
![$ cat /snap/hello-world/current/meta/snap.yaml
name: hello-world
version: 6.3
architectures: [ all ]
summary: The 'hello-world' of snaps
description: |
This is a simple snap example that includes a few interesting binaries
to demonstrate snaps and their confinement.
* hello-world.env - dump the env of commands run inside app sandbox
* hello-world.evil - show how snappy sandboxes binaries
* hello-world.sh - enter interactive shell that runs in app sandbox
* hello-world - simply output text
apps:
env:
command: bin/env
evil:
command: bin/evil
sh:
command: bin/sh
hello-world:
command: bin/echo](https://image.slidesharecdn.com/snapsonopensuse-170527124520/85/Snaps-on-open-suse-9-320.jpg)
![$ cat /snap/hello-world/current/meta/snap.yaml
name: hello-world
version: 6.3
architectures: [ all ]
summary: The 'hello-world' of snaps
description: |
This is a simple snap example that includes a few interesting binaries
to demonstrate snaps and their confinement.
* hello-world.env - dump the env of commands run inside app sandbox
* hello-world.evil - show how snappy sandboxes binaries
* hello-world.sh - enter interactive shell that runs in app sandbox
* hello-world - simply output text
apps:
env:
command: bin/env
evil:
command: bin/evil
sh:
command: bin/sh
hello-world:
command: bin/echo
Name must be unique
Name defines implicit application
Can be changed on existing snaps](https://image.slidesharecdn.com/snapsonopensuse-170527124520/85/Snaps-on-open-suse-10-320.jpg)
![$ cat /snap/hello-world/current/meta/snap.yaml
name: hello-world
version: 6.3
architectures: [ all ]
summary: The 'hello-world' of snaps
description: |
This is a simple snap example that includes a few interesting binaries
to demonstrate snaps and their confinement.
* hello-world.env - dump the env of commands run inside app sandbox
* hello-world.evil - show how snappy sandboxes binaries
* hello-world.sh - enter interactive shell that runs in app sandbox
* hello-world - simply output text
apps:
env:
command: bin/env
evil:
command: bin/evil
sh:
command: bin/sh
hello-world:
command: bin/echo
Version is just a text label
and has no semantics](https://image.slidesharecdn.com/snapsonopensuse-170527124520/85/Snaps-on-open-suse-11-320.jpg)
![$ cat /snap/hello-world/current/meta/snap.yaml
name: hello-world
version: 6.3
architectures: [ all ]
summary: The 'hello-world' of snaps
description: |
This is a simple snap example that includes a few interesting binaries
to demonstrate snaps and their confinement.
* hello-world.env - dump the env of commands run inside app sandbox
* hello-world.evil - show how snappy sandboxes binaries
* hello-world.sh - enter interactive shell that runs in app sandbox
* hello-world - simply output text
apps:
env:
command: bin/env
evil:
command: bin/evil
sh:
command: bin/sh
hello-world:
command: bin/echo
Summary and description.
more meta-data as appstream](https://image.slidesharecdn.com/snapsonopensuse-170527124520/85/Snaps-on-open-suse-12-320.jpg)
![$ cat /snap/hello-world/current/meta/snap.yaml
name: hello-world
version: 6.3
architectures: [ all ]
summary: The 'hello-world' of snaps
description: |
This is a simple snap example that includes a few interesting binaries
to demonstrate snaps and their confinement.
* hello-world.env - dump the env of commands run inside app sandbox
* hello-world.evil - show how snappy sandboxes binaries
* hello-world.sh - enter interactive shell that runs in app sandbox
* hello-world - simply output text
apps:
env:
command: bin/env
evil:
command: bin/evil
sh:
command: bin/sh
hello-world:
command: bin/echo
Applications describe runnable things
● console apps
● desktop apps
● system services
● packaging hooks (in the “hooks:” section)](https://image.slidesharecdn.com/snapsonopensuse-170527124520/85/Snaps-on-open-suse-13-320.jpg)
Snaps on open suse
- 1. Zygmunt Krynicki Snapd developer zygmunt.krynicki@canonical.com Snaps on openSUSE intro, current status and next steps
- 2. About me ● Joined Canonical in 2010 ● snapd developer since ~2016 ● Focused on interfaces and confinement ● Cross-distribution advocate and evangelist
- 3. About this talk ● Introduction to snaps and snapd ● snapd on openSUSE ● Next steps ● ...questions
- 5. What are snaps? ● New packaging format (after debs, clicks and old snaps) ● Strongly unlike classic packages – Read only squashfs images & simple meta-data – Mounted, not unpacked, many revisions kept, deltas, ... – All executables are confined (including package hooks) ● Strongly unlike container images: – Just the app part, system, runtimes, and data are separate – Directly integrated with host system... – ...except for file system layout (mount namespace magic)
- 6. How different? ● Work alongside existing packages and packaging systems – can work standalone for embedded products (all-snap system) – same package works on many distributions ● Different stability levels and releases available at the same time – channels and tracks ● Heavy focus on security and always being up-to-date – Confinement for everything – Automatic hands-free updates Anyone can make a new snap available to everyone in minutes
- 7. Why? One snap to reach them all
- 8. Anatomy of snap packaging ● There are no complex rules – You can put anything you like inside – snapd only cares about meta/snap.yaml – Your package is mounted in a specific place at runtime ● You need most of your dependencies with you – You can use files from the base snap (e.g. core) – You share files (e.g. java/python/... runtime) using content interface and your other snaps.
- 9. $ cat /snap/hello-world/current/meta/snap.yaml name: hello-world version: 6.3 architectures: [ all ] summary: The 'hello-world' of snaps description: | This is a simple snap example that includes a few interesting binaries to demonstrate snaps and their confinement. * hello-world.env - dump the env of commands run inside app sandbox * hello-world.evil - show how snappy sandboxes binaries * hello-world.sh - enter interactive shell that runs in app sandbox * hello-world - simply output text apps: env: command: bin/env evil: command: bin/evil sh: command: bin/sh hello-world: command: bin/echo
- 10. $ cat /snap/hello-world/current/meta/snap.yaml name: hello-world version: 6.3 architectures: [ all ] summary: The 'hello-world' of snaps description: | This is a simple snap example that includes a few interesting binaries to demonstrate snaps and their confinement. * hello-world.env - dump the env of commands run inside app sandbox * hello-world.evil - show how snappy sandboxes binaries * hello-world.sh - enter interactive shell that runs in app sandbox * hello-world - simply output text apps: env: command: bin/env evil: command: bin/evil sh: command: bin/sh hello-world: command: bin/echo Name must be unique Name defines implicit application Can be changed on existing snaps
- 11. $ cat /snap/hello-world/current/meta/snap.yaml name: hello-world version: 6.3 architectures: [ all ] summary: The 'hello-world' of snaps description: | This is a simple snap example that includes a few interesting binaries to demonstrate snaps and their confinement. * hello-world.env - dump the env of commands run inside app sandbox * hello-world.evil - show how snappy sandboxes binaries * hello-world.sh - enter interactive shell that runs in app sandbox * hello-world - simply output text apps: env: command: bin/env evil: command: bin/evil sh: command: bin/sh hello-world: command: bin/echo Version is just a text label and has no semantics
- 12. $ cat /snap/hello-world/current/meta/snap.yaml name: hello-world version: 6.3 architectures: [ all ] summary: The 'hello-world' of snaps description: | This is a simple snap example that includes a few interesting binaries to demonstrate snaps and their confinement. * hello-world.env - dump the env of commands run inside app sandbox * hello-world.evil - show how snappy sandboxes binaries * hello-world.sh - enter interactive shell that runs in app sandbox * hello-world - simply output text apps: env: command: bin/env evil: command: bin/evil sh: command: bin/sh hello-world: command: bin/echo Summary and description. more meta-data as appstream
- 13. $ cat /snap/hello-world/current/meta/snap.yaml name: hello-world version: 6.3 architectures: [ all ] summary: The 'hello-world' of snaps description: | This is a simple snap example that includes a few interesting binaries to demonstrate snaps and their confinement. * hello-world.env - dump the env of commands run inside app sandbox * hello-world.evil - show how snappy sandboxes binaries * hello-world.sh - enter interactive shell that runs in app sandbox * hello-world - simply output text apps: env: command: bin/env evil: command: bin/evil sh: command: bin/sh hello-world: command: bin/echo Applications describe runnable things ● console apps ● desktop apps ● system services ● packaging hooks (in the “hooks:” section)
- 14. $ tree /snap/hello-world/current/ /snap/hello-world/current/ ├── bin │ ├── echo │ ├── env │ ├── evil │ └── sh └── meta ├── gui │ └── icon.png └── snap.yaml 3 directories, 6 files Snapd only cares about the meta/ directory
- 15. $ ls -lR /snap/bin/hello-world* ... /snap/bin/hello-world -> /usr/bin/snap ... /snap/bin/hello-world.env -> /usr/bin/snap ... /snap/bin/hello-world.evil -> /usr/bin/snap ... /snap/bin/hello-world.sh -> /usr/bin/snap Automatically generated launchers for apps. They set up execution environment, confinement and other needed things.
- 17. Snapcraft, a way of building snaps ● snapcraft.yaml describes how to build a snap out of parts. – Superset of snap.yaml shown earlier ● Each part uses a domain-specific build system – ant, catkin, copy, go, gradl, jdk, kernel, maven, nodejs, python, python2, python3, rust, tar-content, autotools, cmake, dump, godeps, gulp, kbuild, make, nil, plainbox- provider, qmake, scons, waf ● Parts can be shared and reused by others
- 18. Snapcraft, a way of building snaps # typical snap.yaml content not shown here parts: cli: plugin: cmake source: https://github.com/…examples.git source-subdir: 01-hello-world-cli/src service: plugin: nodejs source: https://github.com/...examples.git source-subdir: 02-hello-world-service
- 23. Sandboxen ● snapd builds a sandbox around each snap and each runnable entity inside (app/hook) ● Each snap sees its own private mount namespace ● LSMs, seccomp, etc, dictate what may be done ● Same confinement for everything by default ● snapd interfaces create bumps and funnels in the bubble around each runnable. – Allow connecting snaps with the system or other snaps.
- 24. Plugs and slots, connections ● Interfaces are not like android permissions ● Interfaces come in pairs, plugs and slots ● Plug says that a snap may use something ● Slot says that a snap may offer something ● Connections between them shape the sandbox ● Given plug/slot may have more than one connection
- 25. Not your grandpa’s ACLs ● Some slots are offered by the core snap – Those do look like android permissions – But they are not, they are really better :) ● No “do you want to allow $technobabble” questions, ever! ● Any snap may have both plugs and slots – powerful interfaces are restricted and require review ● Snaps offering services to the system and other snaps – Bluez, network manager, modem manager, udisks2... ● Connections form a graph between snaps – Connections can carry state
- 26. 91 interfaces and counting ● From network that lets you talk to the network to raw-usb that lets you talk to USB gizmos, through opengl, and bluez and many others. ● Interfaces define the protocol of communication: – Specific IPC or specific API or specific files or specific behaviour – As long as the interface is the same the slot may be interchangeable and provided by anyone.
- 27. Devmode ● Confinement can be switched into advisory mode during development – devmode snaps not shown in package managers – Users have to acknowledge installation – Scary, scary wording to ward off social engineering ● devmode helps in bringing up snaps quickly
- 29. Snappy store ● SAAS offering from Canonical – Free to use for everyone – Commercial stores available on demand – Relatively simple HTTP protocol, a few endpoints ● Store is not a classic distribution repository – Semantics are quite different – But this slide is too short to say why
- 30. Store responsibilities ● Store handles search, delivery, deltas and developer workflow (registration, uploads, review, publication and payments) ● Organizes snaps into tracks and channels ● Tells snapd which revision of each snap to use – e.g. on x86_64 tracking mysql 5.7/beta get revision 3
- 31. Snaps names and revisions ● Snaps have a flat namespace – You look for name, you get an ID – Names can be claimed and pulled away (e.g. for legal reasons) without changing existing snaps ● Store allocates revision numbers – Each uploaded squashfs gets a revision – They are not versions, they are not ordered – Each architecture-specific build is another revision
- 32. Tracks & channels ● snap install –-channel=2.0/beta mysnap ● Snaps are published to channels – risk level: stable (confined!), candidate, beta or edge – track: latest/stable, 2.x/beta, (any track name) ● Each snap tracks a given channel – Not all-or-nothing “latest” – as stable or rolling as you want, per snap
- 33. Snapd (service)
- 34. Snapd (service) ● FOSS, GPLv3 ● 83 contributors, 19,000+ commits, 137 releases ● Written in Go and some C – Go is safer and easier to write than C – C needed in the plumbing layer mostly – Strong resiliency to errors, recovery and healing features when things fail or break
- 35. Snapd overview ● Processes requests from snap (the CLI) or things like GNOME software through a REST API ● Installs, removes and keeps snaps up-to-date – Snaps are refreshed periodically – Deltas keep the downloads small ● Handles interfaces and security – Manges interface connections and updates sandbox configuration for each runnable entity
- 37. Past and present ● Initial work started ~ may 2016 ● Effort to bring snapd to all popular distributions ● Many bugs and assumptions fixed ● But lost in golang packaging process of the day – Snapd lived in system:snappy in broken state ● Fixed and updated in ~march 2017 and works since
- 38. Where we are now ● Stable package available for openSUSE Leap 42 and Tumbleweed via system:snappy repository ● Uses regular dependencies but vendors golang libraries – Saves on QA and divergence analysis – Saves on time and churn ● Enrolled in per-pull-request CI (since may 2017)
- 39. CI and testing ● Each PR gets built and tested on about a dozen different OS, architecture and release combinations ● 100s of x86_64 and x86 VMs running 24/7 in the public cloud, available to all developers ● Some ARM, Power and S390 VMs in private cloud ● Growing number of physical machines for testing on ARM (though only the core variant for now) ● Manual and exploratory testing before promotion
- 40. What’s next ● Enable all integration tests on openSUSE – Test Tumbleweed as well as LEAP ● Work on adding the package to Factory – Need an experienced packager as guide ← help! – Is golang packaging still in flux? ● But there’s one more thing...
- 41. Apparmor ● Ubuntu used apparmor with phone click packages and with the snappy 1.x (aka 15.04) series. Lots of work went into fixing bugs and adding features. ● Upstreaming in progress – 4.13 as likely target ● Merge them earlier to get full confinement – Did I mention there are many bugs fixed too? – We have branches re-based on various releases
- 42. Help wanted ● Use snaps, report issues, suggest improvements ● Snap your stuff or stuff you love – Caveat: non-ubuntu base snaps 2-3 months away ● Help with packaging snapd – Review, comment, improve – Help with golang bits ● Merge apparmor kernel patches, get fully confined
- 43. Get involved!
- 44. How to find us ● We’re on Freenode #snappy – Though your timezone and connection may vary ● We’re on Rocket #snapcraft (rocket.ubuntu.com) – Modern IRC, lots of snappers there! ● We’re on Discourse (forum.snapcraft.io) – Structured discussions, planning and documentation – Forum is amazing and full of vibe
- 45. Come and visit! ● The snappy team is sprinting in UK – June 26 – June 30 – Hosted at London Canonical office – Come and visit if you care about snaps ● https://forum.snapcraft.io/t/development-sprint-mid-2017/
- 46. Join Us at www.opensuse.org http://snapcraft.io/
- 47. License This slide deck is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license. It can be shared and adapted for any purpose (even commercially) as long as Attribution is given and any derivative work is distributed under the same license. Details can be found at https://creativecommons.org/licenses/by-sa/4.0/ General Disclaimer This document is not to be construed as a promise by any participating organisation to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. openSUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for openSUSE products remains at the sole discretion of openSUSE. Further, openSUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All openSUSE marks referenced in this presentation are trademarks or registered trademarks of SUSE LLC, in the United States and other countries. All third-party trademarks are the property of their respective owners. Credits Template Richard Brown rbrown@opensuse.org Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/