IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If one wants to set up a mount for `/var` in `/etc/fstab`, it
won't be mounted since `ostree-prepare-root` set up a bind mount for
`/var` to `/sysroot/ostree/$stateroot/var`, and systemd will take
the already extant mount over what's in `/etc/fstab`.
There are a few options to fix this, but what I settled on is parsing
`/etc/fstab` in a generator (exactly like `systemd-fstab-generator` does),
except here we look for an explicit mount for `/var`, and if one *isn't* found,
synthesize the default ostree mount to the stateroot. Another nice property is
that if an admin creates a `var.mount` unit in `/etc` for example, that will
also override our mount.
Note that today ostree doesn't hard depend on systemd, so this behavior only
kicks in if we're built with systemd *and* libmount support (for parsing
`/etc/fstab`). I didn't really test that case though.
Initially I started writing this as a "pure libc" program, but at one point
decided to use `libostree.so` to find the booted deployment. That didn't work
out because `/boot` wasn't necessarily mounted and hence we couldn't find the
bootloader config. A leftover artifact from this is that the generator code
calls into libostree via the "cmd private" infrastructure. But it's an easy way
to share code, and doesn't hurt.
Closes: #859
Approved by: jlebon
There are currently no unstable APIs, but some will be added in
following commits. They will be built and exposed in the libostree
global symbol list iff configured with --enable-experimental-api.
Distributions should not package OSTree with --enable-experimental-api.
This is designed for previewing new APIs on controlled platforms; any of
the APIs hidden behind this option may be changed or removed at any
point.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #832
Approved by: cgwalters
The major reason to do this is that running tests *both* installed
and uninstalled in our CI is a mostly pointless waste of time.
Particularly given we have a few expensive tests.
We *do* have tests that only run uninstalled (since they require
the source code) like `test-symbols.sh`.
Hence, add `--enable-installed-tests=exclusive` to mean *only* do installed for
most tests.
We'll still have uninstalled coverage via the Travis/Debian configs, and we
could perhaps do another build with a subset of uninstalled tests, but I'm not
really concerned about it.
I'd like to do a renewed push for the InstalledTests model since
I feel it's just fundamentally better. (`g-d-t-r` kind of sucks,
but then so does the automake runner).
Also while we're here - fix the CI to use the correct context,
which started this mess.
Closes: #837
Approved by: dbnicholson
This commit won't actually *be* 2017.5 since due to the way our infrastructure
works, we still want to increment git master to 2017.5.
See https://github.com/ostreedev/ostree/pull/800Closes: #800
Approved by: jlebon
(Also rename the other CI contexts to be more consistent)
We pass this right now. I just noticed an instance of this in bwrap, and I think
we should be trying to match the RPM build baseline.
Closes: #765
Approved by: jlebon
This actually worked before because `pkg-config --cflags openssl`
is empty, and the linker was satisfying `-lssl -lcrypto` from our
indirect dependencies.
Also, in fact we *currently* just want `pkg-config libcrypto` i.e.
`-lcrypto`, since we aren't actually using openssl to speak TLS.
This doesn't actually matter on Fedora at least since they're both in the
`openssl-libs` package, but they are separate for a reason.
Closes: #749
Approved by: jlebon
Add an OpenSSL backend to the checksum input stream, which is where we do a lot
of checksumming (object commit, static deltas).
The raw OpenSSL performance is
[approximately double](https://gist.github.com/cgwalters/169349fd1c06fd4fb4d3a7ce33303222) on
my laptop; not only does OpenSSL have e.g. hand-tuned x86_64 assembly, the
current implementation uses the
[Intel SHA extensions](https://en.wikipedia.org/wiki/Intel_SHA_extensions).
Another reason to do this is I was idly thinking about adding
[Curve25519](https://en.wikipedia.org/wiki/Curve25519) signatures (like e.g.
Alpine does) instead of/in addition to GPG. The rationale for that is
that GPG is pretty heavyweight, both in code footprint and the simple
fact that EC keys are way smaller.
I didn't benchmark ostree with this; we have bigger performance problems
really like the fact we just malloc way too much. But, it's a step
in the right direction I think in combination with the libcurl work
where we're linking to openssl anyways.
Closes: #738
Approved by: jlebon
This goes farther along the path of deprecating it; consumers should
have been ported at this point. Though probably a lot of people
may still use `rpm-ostree-toolbox`.
Closes: #723
Approved by: jlebon
OSTree currently provides no way to inspect the versioning
information at run time, being only available at compile
time through pkg-config.
This is a problem for e.g. Flatpak, that needs to check
whether the 'update-frequency' option is available. Checking
at compile time isn't great since it's not looking for new
symbols, but only if an optional feature is present.
This commit, then, adds a new header that is generated
at compile time, exposing OSTree's versioning information.
Closes: #728
Approved by: cgwalters
It's been almost a month, I think the current git is working well and
not too risky. We have some new API additions which I think the
various consumers of them are going to want.
Closes: #726
Approved by: jlebon
I've seen code in a few places that I think on balance is definitely better this
way. Some of our functions have huge variable declaration sections.
This change includes one small example where we could start using declarations
after statements.
A concern I had was - how does this interact with `__attribute__((cleanup))` and
early returns? I tested it, and AFAICS the behavior is what you'd expect - the
cleanup function isn't called if its variable isn't reachable.
Closes: #718
Approved by: jlebon
If --enable-man=maybe (the default), and xsltproc is not available, the
configuration code would check for it, correctly set enable_man=no, then
incorrectly overwrite that with enable_man=yes, which would result in
later trying to execute $(XSLTPROC) when it’s empty.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #720
Approved by: cgwalters
https://github.com/ostreedev/ostree/pull/705 broke the build
on CentOS 7 which only has util-linux 2.23.
When I was thinking about this, I realized that there must really be a way to
make this safe even for older versions. Looking at that version of util-linux,
all we need to do is invert the order of frees so we `mnt_free_table()` *before*
`mnt_free_cache()`, like util-linux does:
https://github.com/karelzak/util-linux/blob/stable/v2.23/sys-utils/eject.c#L1131
We still use the `_unref()` versions if available. I also fixed
the ordering there too for double plus redundant safety.
Closes: #712
Approved by: jlebon
I learned today that `docker version` does this and I really like
the idea. While we have the patient open, also add the gitrev
with code taken from https://github.com/projectatomic/rpm-ostree/pull/584Closes: #691
Approved by: giuseppe
We should get a release out to try to keep with at least a once-a-month cadence.
This one has some exciting stuff like libcurl and Rust, and various bugfixes.
Also importantly I want to cut this *before* we land some other bigger stuff, so
rpm-ostree can start using the reload_config API etc.
Closes: #685
Approved by: jlebon
For rpm-ostree, we already link to libcurl indirectly via librepo, and
only having one HTTP library in process makes sense.
Further, libcurl is (I think) more popular in the embedded space. It
also supports HTTP/2.0 today, which is a *very* nice to have for OSTree.
This seems to be working fairly well for me in my local testing, but it's
obviously brand new nontrivial code, so it's going to need some soak time.
The ugliest part of this is having to vendor in the soup-url code. With
Oxidation we could follow the path of Firefox and use the
[Servo URL parser](https://github.com/servo/rust-url). Having to redo
cookie parsing also sucked, and that would also be a good oxidation target.
But that's for the future.
Closes: #641
Approved by: jlebon
This is an initial drop of "oxidation", or adding implementation
of components in Rust. The bupsplit code is a good target - no
dependencies, just computation.
Translation into Rust had a few twists -
- The C code relies a lot on overflowing unsigned ints, and
also on the C promotion rules for e.g. `uint8_t -> int32_t`
- There were some odd loops that I introduced bugs in while
translating...in particular, the function always returns `len`,
but I mistakenly translated to `len+1`, resulting in an OOB
read on the C side, which was hard to debug.
On the plus side, an off-by-one array indexing in the Rust code paniced nicely.
In practice, we'll need a lot more build infrastructure to make this work, such
as using `cargo vendor` when producing build artifacts for example. Also, Cargo
is yet another thing we need to cache.
Where do we go with this? Well, I think we should merge this, it's not a lot of
code. We can just have it be an alternative CI target. Should we do a lot more
right now? Probably not immediately, but I find the medium/long term prospects
pretty exciting!
Closes: #656
Approved by: jlebon
There are many motivating factors. The biggest is simply that at a practical
level, the command line is not sufficient to build a real system. The docs say
that it's a demo for the library. Let's make that more obvious, so people don't
try to use `ostree admin upgrade` for their real systems, and also don't use
e.g. `ostree commit` on the command line outside of test suites/quick hacking.
This change will also help clarify the role of rpm-ostree, which we will likely
be renamed to "nts". Then use of the term "ostree" will become much clearer. And
similarly for other people writing upgraders, they can say they use libostree.
I didn't try to change all of the docs and code at once, because it's going to
lead to conflicts.
The next big steps are:
- Rename the github repo (github will inject a redirect)
- Look at supporting a build where we don't do `ostree admin`, or at least
it's only built for tests. We may want to split it off as a separate binary
or so? That way people with their own upgraders don't need to ship it.
Closes: #659
Approved by: jlebon
Unfortunately, introspection uses dlopen(), which doesn't quite
work when the DSO is compiled with ASAN but the outer executable
isn't.
Trying to inject LD_PRELOAD=libasan means the outer executable has to
be leak free...which, yeah, I'm not going to get into running ASAN
today on gjs or pygobject.
So, let's skip those tests - ideally, we still run them in some other
context without the sanitizers. The coverage we have from them is
middling anyways.
Closes: #622
Approved by: jlebon
This pulls in a new compilation flag for wrpseudo compatibility. Also
note we need to add some includes since glnx-libcontainer went away,
and with it some includes for `sys/mount.h` etc.
Closes: #522
Approved by: cgwalters
If the `--with-static-compiler=musl-gcc` configure flag is given.
ostree-prepare-root can be used as init in a system without a populated
/lib. To support this use case we need to link statically as we will be
unable to locate libc.so at run time if it's not installed in /lib.
We support building ostree-prepare-root with a different compiler to the
rest of ostree so we can use musl rather than glibc. This reduces the size
of the executable significantly: from ~700K -> ~30K. We have to use
`_SCRIPTS` here to get autotools to install this as an executable but
without generating rules to make it itself which we have specified
manually.
See https://lists.gnu.org/archive/html/help-gnu-utils/2007-01/msg00007.html
for advice on using autotools in this manner.
Closes: #477
Approved by: cgwalters
Lots and lots of preparation led to this moment - when nothing
apparent changes for users! Woo!
But seriously, having the extra dependency is a minor annoyance, and
in the big picture I think the libgsystem idea was wrong - we need to
land things in GLib, and use git submodules for API-unstable or
Linux-specific sharing. For a lot of OSTree, the libgsystem `GFile*`
orientation was also wrong, we really want fd-relative.
Closes: #444
Approved by: jlebon
I want to add `-Werror=int-conversion`, but it's only available in
newer GCC versions. So let's start autodetecting available compiler
flags.
Closes: #431
Approved by: giuseppe
In general this is even cleaner now, though it was better after I
extracted a helper function for the "write tempfile with contents"
bits that were shared between metadata and regular file codepaths.
Closes: #369
Approved by: jlebon
This was the last caller of libgsystem that isn't
`gs_file_get_path_cached()`. I think the use case ostree has where
the same code can be called via command line and via a shared library
*and* via a daemon is rather unusual, so let's just copy the code for
logging from libgsystem into here.
For example rpm-ostree hard depends on a daemon mode, so it'll just
use `sd_journal` directly.
Closes: #341
Approved by: jlebon
The AC_PROG_YACC already does the checking for us, so we don't need to
use AC_CHECK_PROGS (which wasn't working anyway because autoconf didn't
run the check thinking it was cached already from the earlier
AC_PROC_YACC, so we didn't get the default ":" value)
Closes: #325
Approved by: cgwalters
It's actually just easier for build systems (e.g. rpm-ostree)
using dracut to use `--add ostree` rather than indirecting
through the conf file.
This makes it easier for yum-managed systems to install ostree without
side effects.
Closes: #279
Approved by: gatispaeglis
If one happens to not have grub2 installed, the previous commit
would cause us to fall back to `grub-mkconfig` with bad results.
We should likely just do dynamic detection and avoid pain, but
there's no harm in also allowing this to be statically determined.
The automagic here is that if `/etc/os-release` says `ID_LIKE=fedora`,
we know to use `grub2-mkconfig`. But distro scripts should set this
in the build configurations using `--with-grub2-mkconfig=`.
Closes: #240
Approved by: jlebon
ostree-grub-generator can be used to customize
the generated grub.cfg file. Compile time
decision ostree-grub-generator vs grub2-mkconfig
can be overwritten with the OSTREE_GRUB2_EXEC
envvar - useful for auto tests and OS installers.
Why this alternative approach:
1) The current approach is less flexible than using a
custom 'ostree-grub-generator' script. Each system can
adjust this script for its needs, instead of using the
hardcoded values from ostree-bootloader-grub2.c.
2) Too much overhead on embedded to generate grub.cfg
via /etc/grub.d/ configuration files. It is still
possible to do so, even with this patch applied.
No need to install grub2 package on a target device.
3) The grub2-mkconfig code path has other issues:
https://bugzilla.gnome.org/show_bug.cgi?id=761180
Task: https://bugzilla.gnome.org/show_bug.cgi?id=762220Closes: #228
Approved by: cgwalters
I'd like to encourage people to make OSTree-managed systems more
strictly read-only in multiple places. Ideally everywhere is
read-only normally besides `/var/`, `/tmp/`, and `/run`.
`/boot` is a good example of something to make readonly. Particularly
now that there's work on the `admin unlock` verb, we need to protect
the system better against things like `rpm -Uvh kernel.rpm` because
the RPM-packaged kernel won't understand how to do OSTree right.
In order to make this work of course, we *do* need to remount `/boot`
as writable when we're doing an upgrade that changes the kernel
configuration. So the strategy is to detect whether it's read-only,
and if so, temporarily mount read-write, then remount read-only when
the upgrade is done.
We can generalize this in the future to also do `/etc` (and possibly
`/sysroot/ostree/` although that gets tricky).
One detail: In order to detect "is this path a mountpoint" is
nontrivial - I looked at copying the systemd code, but the right place
is to use `libmount` anyways.
OSTree's code for testing predates the `glib-tap.mk` making its
way into GLib. Let's switch to it, as it provides a number
of advantages.
By far the biggest advantage is that `make check` can start to run
most of the tests *in addition* to having them work installed.
This commit keeps the installed tests working, but `make check` turns
out to be really broken because...our TAP usage has bitrotted to say
the least. Fix that all up.
Do some hacks so that the tests work uninstalled as well - in
particular, `glib-tap.mk` and the bits encoded into
`g_test_build_filename()` assume *recursive* Automake (blah). Work
around that by creating a symlink when installed to loop back.
While it's not strictly tied to OSTree, let's move
https://github.com/cgwalters/rofiles-fuse in here because:
- It's *very* useful in concert with OSTree
- It's tiny
- We can reuse OSTree's test, documentation, etc. infrastructure
One thing to consider also is that at some point we could experiment
with writing a FUSE filesystem for OSTree. This could internalize a
better equivalent of `--link-checkout-speedup`, but on the other hand,
the cost of walking filesystem trees for these types of operations is
really quite small.
But if we did decide to do more FUSE things in OSTree, this is a step
towards that too.
This is preparation for introducing a `mkdocs` manual under `doc/`
which should be significantly more useful for the world at large than
the minimal manual that exists there now.
A lot of effort here just to avoid touching SoupSession directly in
ostree_fetcher_new(). The reason will become apparent in subsequent
commits.
Note this introduces generated enum/flags GTypes using glib-mkenums.
I could have just made the property type as plain integer, but doing
properties right will henceforth be easier now that the automake-fu
is established.
Use the parse-datetime module from gnulib, and adapt it to not require
other modules as portability is not really an issue for us.
DATE can be specified in different formats, such as: "-1 week", "last
monday", "1 week ago".
Include the generated .c file in the repository so to not add another
dependency to Bison.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
In anticipation of API enhancements for GPG signature verification, which
would otherwise require a non-functional stub version were GPGME excluded.
GPGME is a pretty lightweight dependency, and the motivation to exclude
it is not clear.
In this approach, we drop a /etc/grub.d/15_ostree file which is a
hybrid of shell/C that picks up bits from the GRUB2 library (e.g. the
block device script generation), and then calls into libostree's
GRUB2 code which knows about the BLS entries.
This is admittedly ugly. There exists another approach for GRUB2 to
learn the BLS specification. However, the spec has a few issues:
https://www.redhat.com/archives/anaconda-devel-list/2014-July/msg00002.html
This approach also gives a bit more control to the admin via the
naming of the 15_ostree symlink; they can easily disable it:
Or reorder the ostree entries ahead of 10_linux:
Also, this approach doesn't require patches for grub2, which is an
issue with the pressure to backport (rpm-)OSTree to EL7.
This prevents people from creating new directories there and expecting
them to be persisted. The OSTree model has all local state to be in
/etc and /var.
This introduces a compile-time dependency on libe2fsprogs.
We're only doing this for the root directory at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=728006
The trees as shipped come with /usr/etc, which should just be labeled
as usr_t. When we do a deployment, we need to relabel the copies of
the files we're making in /etc.
SELinux support is compile and runtime optional.
Add an optional dependency on gpgme to add GPG signatures into the
detached metadata, with the key "ostree.gpgsigs", as an "aay", an
array of signatures (treated as binary data).
The commit command gains a --gpg-sign=<key-id> argument. Also add an
argument --gpg-homedir to set the GPG homedir where we look for
keyrings.
Debian uses /lib/systemd/system for system unit files, while i'm
putting ostree under the /usr prefix which means the hardcoded path
fails. Leave it to configure to work out the right location for systemd
units (method copied from pollkit).
Furthermore instead of installing the unit in local-fs.target.wants by
hand add a [Install] section so systemctl enable does the right thing
https://bugzilla.gnome.org/show_bug.cgi?id=705864
Originally, the idea was that clients would replicate "OS/tree"s from
a build server, but we'd run things like "ldconfig" on the client.
This was to allow adding e.g. the nVidia binary driver.
However, the triggers were the only thing in the system at the moment
that really had expected knowledge of the *contents* of the OS, like
the location of binaries.
For now, it's architecturally cleaner if we move the burden of
triggers to the tree builder (e.g. gnome-ostree or RPM). Eventually
we may want OSTree to assist with this type of thing (perhaps
something like RPM %ghost), but this is the right thing to do now.
This installs a Dracut module which parses the ostree= kernel command
line argument, and if given, sets up the OS/ at /sysroot, which
systemd's switch-root then moves into. This only works if dracut is
configured to use systemd itself.
The collection of Python scripts here have gotten to the point where
we need to share code. Start refactoring things so that we have one
main command which imports subcommands as libraries.
We really want the ability to take a .tar.gz and directly import
it into a repository, without creating a temporary filesystem tree.
First, doing it this way is significantly faster. Also, this allows
us to handle importing tar files with e.g. uid 0 files into packed
repositories as non-root, which is very useful for tests and builds.
This necessitated a large set of changes.
We now support an "archive" mode for repositories. In this mode,
files are stored "packed" rather than hard linked. This allows one to
e.g. store an OSTree repository with root-owned files as non-root. It
is also used as the basis for serving repositories via HTTP.
While doing this I realized that GVariant is endianness-dependent; I
decided to just store all data in big endian.
