Permalink
Browse files

docs: moved to github.com/snapcore/snapd/wiki (#2258)

  • Loading branch information...
1 parent 1c6d1e4 commit c7a8570c49d5923d2f20798c610448fdd281ed92 @niemeyer niemeyer committed on GitHub Nov 3, 2016
Showing with 1 addition and 2,191 deletions.
  1. +1 −0 docs/MOVED.md
  2. +0 −73 docs/assertions.md
  3. +0 −48 docs/autoupdate.md
  4. +0 −128 docs/config.md
  5. +0 −35 docs/cross-build.md
  6. +0 −34 docs/gadget.md
  7. +0 −70 docs/garbage.md
  8. +0 −105 docs/hooks.md
  9. +0 −520 docs/interfaces.md
  10. +0 −126 docs/meta.md
  11. +0 −138 docs/package-names.md
  12. +0 −56 docs/prepare-image.md
  13. +0 −655 docs/rest.md
  14. +0 −203 docs/security.md
View
@@ -0,0 +1 @@
+### Moved to https://github.com/snapcore/snapd/wiki
View
@@ -1,73 +0,0 @@
-# Snapd assertions
-
-A summary of the supported assertions of snapd.
-
-## Account
-
-Account holds an account assertion, which ties a name for an to its
-identifier and provides the authority's confidence in the name's
-validity.
-
-## AccountKey
-
-AccountKey holds an account-key assertion, asserting a public key
-belonging to the account.
-
-## Model
-
-Model holds a model assertion, which is a statement by a brand
-about the properties of a device model.
-
-## Serial
-
-Serial holds a serial assertion, which is a statement binding a
-device identity with the device public key.
-
-## SnapDeclaration
-
-SnapDeclaration holds a snap-declaration assertion, declaring a
-snap binding its identifying snap-id to a name, asserting its
-publisher and its other properties.
-
-## SnapBuild
-
-SnapBuild holds a snap-build assertion, asserting the properties of a snap
-at the time it was built by the developer.
-
-## SnapRevision
-
-SnapRevision holds a snap-revision assertion, which is a statement by the
-store acknowledging the receipt of a build of a snap and labeling it with a
-snap revision.
-
-## System-user
-
-SystemUser holds a system-user assertion which allows creating local
-system users.
-
-The system-user assertion has the following form:
-```
-type: system-user
-authority-id: account-id // Owner of the key, must be the brand
-brand-id: account-id // Assertion will only work on models of this brand
-email: string // Email of user
-series: list // List of series which should accept this assertion
-models: list // Models which should accept this assertion
-name: string // Optional person’s name, for context and for gecos
-username: string // Local system username for the user
-password: string // Password for local system user, encoded and salted with
- an algorithm hard to brute-force ($6$rounds=...$...)
-ssh-keys: list // SSH keys to authorize for connection
-since: utc-datetime
-until: utc-datetime // Required!
-revision: integer
-
-signature authority-sig
-```
-
-## Validation
-
-Validation holds a validation assertion, describing that a combination of
-(snap-id, approved-snap-id, approved-revision) has been validated for
-the series, meaning updating to that revision of approved-snap-id
-has been approved by the owner of the gating snap with snap-id.
View
@@ -1,48 +0,0 @@
-# Autoupdate
-
-*Autoupdate* is a feature that will guarantee you are always up to
-date. It is enabled by default, and can be disabled via `snappy config`.
-
-## Usage
-
-To check whether the feature is active, run
-
- snappy config ubuntu-core | grep autoupdate
-
-If you want to disable it run
-
- echo 'config: {ubuntu-core: {autoupdate: off}}' | sudo snappy config ubuntu-core -
-
-and you then re-enable it via
-
- echo 'config: {ubuntu-core: {autoupdate: on}}' | sudo snappy config ubuntu-core -
-
-Every time autoupdate triggers it will try to update the whole system;
-if an `ubuntu-core` update is available the system will automatically
-reboot, although a message is printed to console with instructions on
-how to abort the reboot, in case you are logged in at the time.
-
-> If you need a single configuration that works both on 15.04 and rolling, you
-> can use both the old and new keys, e.g. `config: {ubuntu-core: {autoupdate:
-> on, autopilot: on}}`.
-
-## Implementation details
-
-Autoupdate used to be called *autopilot* (but that got very confusing,
-especially when people were using snappy with other things that have
-their own autopilot, like an OpenStack deployment that used
-Canonical's own OpenStack Autopilot, or in mobile robots that could
-fly themselves); the `systemd` units still use this name.
-
-For more details of when it is to be triggered you could dig into the
-implementation, via
-
- systemctl list-timers snapd.refresh.timer
-
-To check whether the update ran, run
-
- systemctl status -l snapd.refresh.service
-
-and to view any output from the command run
-
- sudo journalctl -u snapd.refresh.service
View
@@ -1,128 +0,0 @@
-Snappy config
-=============
-
-The snappy config command is a mechanism for package to provide a way
-to set and get its configuration. A standard yaml based protocol is
-used for the interaction. The application is responsible for providing
-a configuration handler that can transform yaml into the app's native
-configuration format.
-
-We plan also to support a schema file for the yaml to make editing
-simpler, for example web based editing of config. The format of the
-configuration is as follows:
-
- config:
- packagename:
- key: value
- another-pkg:
- key: value
-
-The application provides a configuration handler in
-`meta/hooks/config`. This configuration handler must provide for reading
-new configuration from stdin and output the current configuration (after
-the new configuration has been applied) to stdout.
-
-The package config hook must return exit code 0 and return valid yaml
-of the form:
-
- config:
- packagename:
- key: value
-
-on stdout.
-
-In addition to the "config" top-level yaml key there is a optional
-"status" key per packagename that contains details about the
-success/failure of get/set the configuration. The current key/value
-pairs are supported right now:
-
- - error: optional error string
- - warning: optional warning string
-
-Some key/value pairs in the configuration are fixed, for example all
-applications that listen to a port must support the "ports" config option.
-
-The current list of values that must be supported (if the feature is used):
-
- - ports: the listen ports (if the application listens to the network)
-
-When the configuration is applied the service will be restarted by
-snappy automatically.
-
-Examples:
----------
-
-Example to set config.
-
-snappy calls meta/hooks/config and sends the following over stdin:
-
- config:
- ubuntu-core:
- timezone: Europe/Berlin
-
- The meta/hooks/config sends the following back:
-
- config:
- ubuntu-core:
- timezone: Europe/Berlin
-
-Example to get a config:
-
-snappy calls meta/hooks/config with empty input. The meta/hooks/config sends
-the following back:
-
- config:
- ubuntu-core:
- timezone: Europe/Berlin
- status:
- ubuntu-core:
- ok: true
-
-Example to set a non-existing config:
-
-snappy -> meta/hooks/config
-
- config:
- ubuntu-core:
- tea-in-the-morning: false
-
-meta/hooks/config exit with status 10 and message:
-
- status:
- ubuntu-core:
- error: Unknown config option "tea-in-the-morning"
-
-[snappy fails the install of the app]
-
-### Example: list items and changing config data locally
-
-Running `snappy config SNAPNAME` command will print the current config of a
-snap:
-
- $ snappy config SNAPNAME
- SNAPNAME:
- config1: value
- config2:
- - listitem1
- - listitem2
-
-To change an existing configuration you would save this output to a local
-YAML file, edit it and use the snappy config command to pass the new YAML
-syntax to the snap:
-
- $ snappy config SNAPNAME > my.yaml
- $ sed -i 's/listitem1/listitem1-changed/'
- $ snappy config SNAPNAME my.yaml
-
-This command will fail with a non-zero exit code if the YAML syntax is not
-valid or the config handler of the snap signals an error.
-
-If it succeeds, the new config is applied:
-
- $ snappy config SNAPNAME
- SNAPNAME:
- config1: value
- config2:
- - listitem1-changed
- - listitem2
-
View
@@ -1,35 +0,0 @@
-# armhf
-
-To cross build for arm you need to install:
-
- sudo apt-get install golang-go-linux-arm
- sudo apt-get install gcc-arm-linux-gnueabihf
-
-And then set up your environment:
-
- export GOARCH=arm GOARM=7 CGO_ENABLED=1 CC=arm-linux-gnueabihf-gcc
-
-With that, `go build` will produce binaries for armhf. E.g.,
-
- go build -o snappy_armhf github.com/snapcore/snapd/cmd/snap
-
-
-As usual, for one-off commands you can simply prepend the environment
-to the command, e.g.
-
- GOARCH=arm GOARM=7 CGO_ENABLED=1 CC=arm-linux-gnueabihf-gcc go build -o snappy_armhf github.com/snapcore/snapd/cmd/snap
-
-
-# arm64
-
-Install:
-
- sudo apt-get install gcc-aarch64-linux-gnu
-
-Setup the environment:
-
- export GOARCH=arm64 CC=aarch64-linux-gnu-gcc CGO_ENABLED=1
-
-And then run:
-
- go build -o snappy_arm64 github.com/snapcore/snapd/cmd/snap
View
@@ -1,34 +0,0 @@
-# Gadget snappy package
-
-The `gadget` snap package is a snap package `type` that is used to setup and
-personalize the system.
-
-There can only be *one* snap package of `type: gadget` and it can only be
-installed during image provision.
-
-## gadget snaps
-
-The gadget snap is a regular snap with some additional files and
-conventions.
-
-### meta/gadget.yaml
-
-The gadget snap has an additional `meta/gadget.yaml` file that describes
-the gadget specific configuration. The `gadget.yaml` structure is:
-
- bootloader: {grub,uboot}
-
-More entries to describe the partitions and bootloader installation
-will be added.
-
-### File layout conventions
-
-The bootloader configuration is expected to be at the toplevel of the
-gadget snap. The filename is `${bootloader_name}.conf`, e.g.
-`grub.conf` or `uboot.conf`. This file will be instaleld into the boot
-partition as `grub.cfg` and `uboot.env`. The bootloader configuration
-contains the boot logic. Examples for the boot logic can be found in
-the `pc` and the `pi2` gadget snaps.
-
-A cloud-init configuration may be provided at the toplevel of the
-gadget snap as `cloud.conf`.
View
@@ -1,70 +0,0 @@
-# Snappy garbage collection
-
-As a snap package is updated, old versions are kept around to enable switching
-back to old, known-good versions using `revert`. *Garbage collection* is
-performed automatically to preserve the ability of doing this revert without
-consuming an overly large amount of disk space.
-
-A snap present in a system can be in several states:
-
-- `installed` (but not active)
-- `active`
-
-When a snap is updated, its data is copied to a new location which is
-used by the updated snap.
-
-Garbage collection is, then, what we call the mechanism of removing and
-purging installed but not active snaps, with the objective of saving disk
-space without compromising the ability to revert your system to a previous
-known-good state.
-
-When you update a snap we'll keep one old snap installed but not active,
-remove and purge the one before that, and anything prior. This means that at
-most two versions of a snap will be present on the system.
-
-Explicitly removing a snap from your system will also remove *and purge* all
-prior versions.
-
-You can disable garbage collection with the `--no-gc` commandline option, or
-when removing or purging a part, by specifying the version on which to operate
-explicitly.
-
-## Example
-
-Let's look at installing and updating `hello-world` through a few
-versions. Let's say you have version 1.0.1 installed, and you do a `snappy
-update` which downloads version 1.0.2,
-
- $ sudo snappy update
- Installing hello-world.canonical (1.0.2)
- Starting download of hello-world.canonical
- 30.99 KB / 30.99 KB [======================]
- Done
- Name Date Version Developer
- hello-world 1-01-01 1.0.2 canonical
- $ snappy list | grep hello
- hello-world 2015-03-31 1.0.2 canonical
- $ snappy list -v | grep hello
- hello-world 2015-03-31 1.0.1 canonical
- hello-world* 2015-03-31 1.0.2 canonical
-
-so, it downloaded `1.0.2`, made it active, and left `1.0.1` installed. Let's
-do it again!
-
- $ sudo snappy update
- Installing hello-world.canonical (1.0.3)
- Starting download of hello-world.canonical
- 30.99 KB / 30.99 KB [======================]
- Done
- Name Date Version Developer
- hello-world 1-01-01 1.0.3 canonical
- $ snappy list -v | grep hello
- hello-world 2015-03-31 1.0.2 canonical
- hello-world* 2015-03-31 1.0.3 canonical
-
-and `1.0.1` is gone.
-
-## Future work and/or discussion
-
-* Do we need to provide configuration options for `.snap` authors to specify
- tweaks to this gc policy?
Oops, something went wrong.

0 comments on commit c7a8570

Please sign in to comment.