f81b9fa166
We've long struggled with semantics for `/var`. Our stance of "/var should start out empty and be managed by the OS" is a strict one, that pushes things closer to the original systemd upstream ideal of the "OS state is in /usr". However...well, a few things. First, we had some legacy bits here which were always populating the deployment `/var`. I don't think we need that if systemd is in use, so detect if the tree has `usr/lib/tmpfiles.d`, and don't create that stuff at `ostree admin stateroot-init` time if so. Building on that then, we have the stateroot `var` starting out actually empty. When we do a deployment, if the stateroot `var` is empty, make a copy (reflink if possible of course) of the commit's `/var` into it. This matches the semantics that Docker created with volumes, and this is sufficiently simple and easy to explain that I think it's closer to the right thing to do. Crucially...it's just really handy to have some pre-existing directories in `/var` in container images, because Docker (and podman/kube/etc) don't run systemd and hence don't run `tmpfiles.d` on startup. I really hit on the fact that we need `/var/tmp` in our container images by default for example. So there's still some overlap here with e.g. `/usr/lib/tmpfiles.d/var.conf` as shipped by systemd, but that's fine - they don't actually conflict per se. |
||
|---|---|---|
| .. | ||
| _sass/color_schemes | ||
| _config.yml | ||
| adapting-existing.md | ||
| atomic-upgrades.md | ||
| authenticated-repos.md | ||
| bootloaders.md | ||
| buildsystem-and-repos.md | ||
| composefs.md | ||
| contributing-tutorial.md | ||
| CONTRIBUTING.md | ||
| deployment.md | ||
| formats.md | ||
| Gemfile | ||
| ima.md | ||
| index.md | ||
| introduction.md | ||
| prep-docs.sh | ||
| README-historical.md | ||
| README.md | ||
| related-projects.md | ||
| repo.md | ||
| repository-management.md | ||
| var.md | ||
This documentation is written in Jekyll format to be published on GitHub Pages. The rendered HTML will be automatically built and published, but you can also use Jekyll locally to test changes.
First you need to install Ruby and
RubyGems to get Jekyll and the other gem
dependencies. This is easiest using the distro's packages. On RedHat
systems this is rubygems and on Debian systems this is
ruby-rubygems.
Next Bundler is needed to install the gems using
the provided Gemfile. You can do this by running gem install bundler or using distro packages. On RedHat systems this is
rubygem-bundler and on Debian systems this is ruby-bundler.
Now you can prepare the Jekyll environment. Change to this directory and run:
bundle config set --local path vendor/bundle
bundle install
Finally, run the prep-docs.sh script and then render and serve the
site locally with Jekyll:
./prep-docs.sh
bundle exec jekyll serve