keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

docs: Point compose server intro to CentOS

Browse Source 
We should make this less abstract and rather point people directly at
the CentOS bits as it's more likely to be a real-world useful example
and produce something they want.

Fix a few other typos and bits.

Closes: #279
Approved by: miabbott
This commit is contained in:
Colin Walters 2016-05-02 15:41:33 -04:00 committed by Colin Walters (automation)
parent 4fc25d74a3
commit 603180bcf2
3 changed files with 44 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
README.md
View File

@ -61,10 +61,7 @@ For more information on this, see `CONTRIBUTING.md`.
More documentation More documentation
------------------ ------------------
New! See the docs online at [Read The Docs (OSTree)](https://ostree.readthedocs.org/en/latest/ ) New! See the docs online at [Read The Docs (rpm-ostree)](https://rpm-ostree.readthedocs.org/en/latest/ )
Some more information is available on the old wiki page:
https://wiki.gnome.org/Projects/OSTree
Contributing Contributing
------------ ------------

6
docs/manual/background.md
View File

@ -35,8 +35,8 @@ on the compose server, clients get it. If one removes a package, it's
also removed when clients upgrade. also removed when clients upgrade.
One simple mental model for rpm-ostree is: imagine taking a set of One simple mental model for rpm-ostree is: imagine taking a set of
packages on the server side, install them to a chroot, then doing `git packages on the server side, install them to a chroot, then doing `git commit`
commit` on the result. And imagine clients just `git pull -r` from on the result. And imagine clients just `git pull -r` from
that. What OSTree adds to this picture is support for file uid/gid, that. What OSTree adds to this picture is support for file uid/gid,
extended attributes, handling of bootloader configuration, and merges extended attributes, handling of bootloader configuration, and merges
of `/etc`. of `/etc`.
@ -51,7 +51,7 @@ backups such as LVM or BTRFS.
## Who should use this? ## Who should use this?
Currently, rpm operates on a read-only mode on installed systems; it Currently, `rpm-ostree` operates on a read-only mode on installed systems; it
is not possible to add or remove anything on the client. If this is not possible to add or remove anything on the client. If this
matches your deployment scenario, rpm-ostree is a good choice. matches your deployment scenario, rpm-ostree is a good choice.
Classic examples of this are fixed purpose server farms, "corporate Classic examples of this are fixed purpose server farms, "corporate

56
docs/manual/compose-server.md
View File

@ -1,35 +1,55 @@
## Installing and setting up a repository ## Background on managing an OSTree repository
Once you have that done, choose a build directory. Here we'll use Before you get started, it's recommended to read (at least) these two sections
/srv/rpm-ostree. of the OSTree manual:
# cd /srv/rpm-ostree - [buildsystem-and-repos](https://ostree.readthedocs.io/en/latest/manual/buildsystem-and-repos/)
- [repository-management](https://ostree.readthedocs.io/en/latest/manual/repository-management/)
## Generating OSTree commits from a CentOS base
First, you'll need a copy of `rpm-ostree` on your compose server.
It's included in the package collection for Fedora, and there are
[CentOS Core packages](http://buildlogs.centos.org/centos/7/atomic/x86_64/Packages/)
as well as [bleeding edge CentOS builds](https://ci.centos.org/job/atomic-rdgo-centos7/).
A good first thing to try would be using the
[CentOS Atomic Host](https://github.com/CentOS/sig-atomic-buildscripts/tree/downstream)
metadata to generate a custom host.
One time setup, where we clone the git repository, then make two
OSTree repos, one for doing builds, one for export via HTTP:
```
# mkdir /srv/centos-atomic
# cd /srv/centos-atomic
# git clone https://github.com/CentOS/sig-atomic-buildscripts -b downstream
# mkdir build-repo
# ostree --repo=build-repo init --mode=bare-user
# mkdir repo # mkdir repo
# ostree --repo=repo init --mode=archive-z2 # ostree --repo=repo init --mode=archive-z2
```
## Running `rpm-ostree compose tree` ## Running `rpm-ostree compose tree`
This program takes as input a manifest file that describes the target This program takes as input a manifest file that describes the target
system, and commits the result to an OSTree repository. system, and commits the result to an OSTree repository.
See also: https://github.com/projectatomic/rpm-ostree-toolbox
The input format is a JSON "treefile". See examples in The input format is a JSON "treefile". See examples in
`doc/treefile-examples` as well as `doc/treefile.md`. `doc/treefile-examples` as well as `doc/treefile.md`.
# rpm-ostree compose tree --repo=/srv/rpm-ostree/repo --proxy=http://127.0.0.1:8123 sometreefile.json ```
# rpm-ostree compose tree --repo=/srv/centos-atomic/build-repo sig-atomic-buildscripts/centos-atomic-host.json
```
All this does is use yum to download RPMs from the referenced repos, This will download RPMs from the referenced repos, and commit the
and commit the result to the OSTree repository, using the ref named by result to the OSTree repository, using the ref named by `ref`.
`ref`. Note that we've specified a local caching proxy (`polipo` in
this case) - otherwise we will download the packages for each
treecompose.
You can export `/srv/rpm-ostree/repo` via any static webserver. Once we have that commit, let's export it:
The use of `--proxy` is not mandatory but strongly recommended - with ```
this option you can avoid continually redownloading the packages every # ostree --repo=repo pull-local build-repo centos-atomic-host/7/x86_64/standard
compose. I personally use ```
[Polipo](http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/),
but you can of course any HTTP proxy you wish.
You can tell client systems to rebase to it by combining `ostree
remote add`, and `rpm-ostree rebase` on the client side.