From 991b4350a8020da9f491e341c352dd61440d1eb3 Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Thu, 18 Oct 2018 00:56:41 +0200 Subject: [PATCH] docs: use h2 headers The primer theme does not add a mouse-over anchor link for h1 headers. So use h2 for subsection headers which looks nicer anyway. Followup for #10421 --- docs/PORTABLE_SERVICES.md | 16 ++++++++-------- docs/TRANSLATORS.md | 4 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/PORTABLE_SERVICES.md b/docs/PORTABLE_SERVICES.md index 55397f4639..4b37a19455 100644 --- a/docs/PORTABLE_SERVICES.md +++ b/docs/PORTABLE_SERVICES.md @@ -20,7 +20,7 @@ Portable services don't bring anything inherently new to the table. All they do is put together known concepts in a slightly nicer way to cover a specific set of use-cases in a nicer way. -# So, what *is* a "Portable Service"? +## So, what *is* a "Portable Service"? A portable service is ultimately just an OS tree, either inside of a directory tree, or inside a raw disk image containing a Linux file system. This tree is @@ -43,7 +43,7 @@ do too. If you so will, "Portable Services" are a nicer way to manage chroot() environments, with better security, tooling and behavior. -# Where's the difference to a "Container"? +## Where's the difference to a "Container"? "Container" is a very vague term, after all it is used for systemd-nspawn/LXC-type OS containers, for Docker/rkt-like micro service @@ -74,7 +74,7 @@ Note that portable services are only available for system services, not for user services. i.e. the functionality cannot be used for the stuff bubblewrap/flatpak is focusing on. -# Mode of Operation +## Mode of Operation If you have portable service image, maybe in a raw disk image called `foobar_0.7.23.raw`, then attaching the services to the host is as easy as: @@ -141,7 +141,7 @@ Note that `portable attach` won't enable or start any of the units it copies out. This still has to take place in a second, separate step. (That said We might add options to do this automatically later on.). -# Requirements on Images +## Requirements on Images Note that portable services don't introduce any new image format, but most OS images should just work the way they are. Specifically, the following @@ -208,14 +208,14 @@ image. To facility 3 and 4 you also need to include a boot loader in the image. As mentioned `mkosi -b` takes care of all of that for you, but any other image generator should work too. -# Execution Environment +## Execution Environment Note that the code in portable service images is run exactly like regular services. Hence there's no new execution environment to consider. Oh, unlike Docker would do it, as these are regular system services they aren't run as PID 1 either, but with regular PID values. -# Access to host resources +## Access to host resources If services shipped with this mechanism shall be able to access host resources (such as files or AF_UNIX sockets for IPC), use the normal `BindPaths=` and @@ -224,7 +224,7 @@ If services shipped with this mechanism shall be able to access host resources `/etc/resolv.conf`, the D-Bus system bus socket or write access to the logging subsystem are available to the service. -# Instantiation +## Instantiation Sometimes it makes sense to instantiate the same set of services multiple times. The portable service concept does not introduce a new logic for this. It @@ -242,7 +242,7 @@ simple as: The benefit of this approach is that templating works exactly the same for units shipped with the OS itself as for attached portable services. -# Immutable images with local data +## Immutable images with local data It's a good idea to keep portable service images read-only during normal operation. In fact all but the `trusted` profile will default to this kind of diff --git a/docs/TRANSLATORS.md b/docs/TRANSLATORS.md index 38c2487b90..9c45453083 100644 --- a/docs/TRANSLATORS.md +++ b/docs/TRANSLATORS.md @@ -14,7 +14,7 @@ Finally, it is able to compile the translations (to `*.gmo` files), so that they can be used by systemd software. (This step is also useful to confirm the syntax of the `*.po` files is correct.) -# Creating a New Translation +## Creating a New Translation To create a translation to a language not yet available, start by creating the initial template: @@ -39,7 +39,7 @@ $ cp po/systemd.pot po/${lang_code}.po Then edit the new po/${lang_code}.po file (for example, using the `poedit` GUI editor.) -# Updating an Existing Translation +## Updating an Existing Translation Start by updating the `*.po` files from the latest template: