This large patch moves the core xattr logic down into libgsystem,
which allows the gs_shutil_cp_a() API to copy them. In turn, this
allows us to just use that API instead of rolling our own recursive
copy here.
As noted in the new comment though, one case that we are explicitly
regressing is where the new /etc removes a parent directory that's
needed by a modified file. This seems unlikely for most vendors now,
but let's do that as a separate bug.
https://bugzilla.gnome.org/show_bug.cgi?id=711058
Previously the progress meter would bump in large chunks after we
completed a download. Instead, poll in progress files via fstat() for
their size, and add those to the running total.
The libostree already treats passing NULL for osname as "booted
osname, if any". We should do the same inside the tools. The upgrade
builtin had this logic duplicated there; we should be able to safely
remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=710970
When booted into an ostree you can deploy without passing
an --os option. That was crashing though, because
ot_admin_complete_deploy_one is called with NULL
osname but it was not handling it properly.
https://bugzilla.gnome.org/show_bug.cgi?id=710970
Several APIs in libostree were moved there from the commandline code,
and have hardcoded g_print() for progress and notifications. This
isn't useful for people who want to write PackageKit backends, custom
GUIs and the like.
From what I can tell, there isn't really a winning precedent in GLib
for progress notifications.
PackageKit has the model where the source has GObject properties that
change as async ops execute, which isn't bad...but I'd like something
a bit more general where say you can have multiple outstanding async
ops and sensibly track their state.
So, OstreeAsyncProgress is basically a threadsafe property bag with a
change notification signal.
Use this new API to move the GSConsole usage (i.e. g_print()) out from
libostree/ and into ostree/.
Add a --generate-sizes option to commit to add size information to the
commit metadata. This will be used by higher level code which wants
to determine the total size necessary for downloading.
The gpgme examples use this, but from what I can tell we don't really
need to because we don't need detailed results; we only care whether
we signed it at all.
We need to use the full shutil_rm_rf() in order to actually delete
complete directories.
Test suite code based on a patch from Sjoerd Simons <sjored@luon.net>
https://bugzilla.gnome.org/show_bug.cgi?id=710097
Adapted from Google protobufs. For several cases, we want to support
e.g. file sizes up to guint64, but paying the cost of 8 bytes for each
number is too high.
This will be used for static deltas and sizes metadata.
If a deployment is somehow in the list twice, the hash table will free
the *new* value with g_hash_table_insert which gets all broken. Just
use g_hash_table_replace().
This commit changes the sysroot API so that one can create arbitrary
new deployment checkouts, then commit them as one step. This is to
enable things like an automatic bisection tool which say create 50
deployments at once, then when done clean them up.
This also moves some printfs from the library into src/ostree.
I plan to rename all of these APIs to use the term 'loose', so that it
makes more sense after pack files are introduced. External users
should not use them; instead use _load_variant() or _read_commit().
This uses gpgv for verification against DATADIR/ostree/pubring.gpg by
default. The keyring can be overridden by specifying OSTREE_GPG_HOME.
Add a unit test for commit signing with gpg key and verifying on pull;
to implement this we ship a test GPG key generated with no password
for Ostree Tester <test@test.com>.
Change all of the existing tests to disable GPG verification.
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.
I was getting hangs in the test suite, and looking at the previous
commit, we were calling the async completion functions out of the
finalizer for the URI, which is weird. I didn't analyze what's going
wrong, but what we really should be doing is processing our internal
queue after we've downloaded a file, and the request is about to be
finalized.
I suspect doing queue management from the finalizer created a circular
reference type situation.
This patch deduplicates the queue processing bits too.
https://bugzilla.gnome.org/show_bug.cgi?id=708126
On a large ostree repository pulling over http slows to a crawl. Pulling
from localhost results in:
5944 metadata, 63734 content objects fetched; 850509 KiB transferred in
1106 seconds
In other words about 800KiB/s. Some profiling shows that essentially
all of the CPU goes into libsoup doing its request bookkeeping instead
of into the actual downloading.
Adding a simple queue to limit to number of active request sent into
libsoup makes for a dramatic improvement:
5944 metadata, 63734 content objects fetched; 850509 KiB transferred
in 89 seconds
So around 9450 KiB/s.
https://bugzilla.gnome.org/show_bug.cgi?id=708126
If we had two deployments with different boot checksums, and were
trying to remove the one that was the same and add a new one (the
normal case), we'd end up assuming due to comparison with 0 that
we only needed to do the fast subbootversion swap.
Fix this by actually putting 1 where we really mean 1.
And update the tests to verify the fix; I have double-verified by
undoing the fix, and noting that the test fails.
https://bugzilla.gnome.org/show_bug.cgi?id=708351
The actual deployment checksum shouldn't be in there, because we may
just swap bootlinks, rendering the name of the old bootloader entry
file invalid. Thankfully nothing actually parsed the names of these
files, so let's just use the index.
This is just something I noticed on inspection; we should catch any
changes to /boot in the sync(), even though theoretically gio should
have done fdatasync().
Now that we have a real GObject for the sysroot, we have a convenient
place to keep track of 4 pieces of state:
* The current deployment list
* The current bootversion
* The current subbootversion
* The current booted deployment (if any)
Avoid requiring callers to pass all of this around and load it
piecemeal; instead the new thing is ostree_sysroot_load().
I ran into Jeremy Katz today, and he gave me permission to relicense
the small bits of switch-root.c to LGPLv2+. This combined with
permission from Peter Jones allows OSTree to become fully LGPLv2+.
Not a big deal, it's just a lot clearer to only have one license, and
it makes it easier to turn application code into library code.
read_commit resolves the ref to a commit, and a lot of consumers want
the resolved commit for their own purposes; this prevents them from
calling resolve_rev themselves.
https://bugzilla.gnome.org/show_bug.cgi?id=707727
We want an OstreeRepoFile to be the way to reference a "filesystem
tree" that's stored in the repo, which is a combination of a DIR_TREE
and a DIR_META. The idea is that once you write an mtree to the repo
using ostree_repo_write_mtree, it becomes serialized and you get an
OstreeRepoFile in return.
Change any APIs that care about DIR_TREE / DIR_META checksums to care
about OstreeRepoFiles instead, which right now is mostly is
ostree_repo_write_commit.
https://bugzilla.gnome.org/show_bug.cgi?id=707727
We want an OstreeRepoFile to be the way to represent a filesystem tree
inside an ostree repository. In order to do this, we need to drop the
commit from an OstreeRepoFile, and make that go to callers.
Switch all current users of ostree_repo_file_new_root to
ostree_repo_read_commit, and make the actual constructor private.
https://bugzilla.gnome.org/show_bug.cgi?id=707727
Previously I thought we'd have to ditch the current commit
format to avoid a{sv} due to
See https://bugzilla.gnome.org/show_bug.cgi?id=673012
But I realized that we don't really have to care about
unpacking/repacking commit objects, so let's just re-expose the
existing metadata a{sv} in commits in the API.
Also, add support for "detached" metadata that can be updated at any
time post-commit. This is specifically designed for GPG signatures.
https://bugzilla.gnome.org/show_bug.cgi?id=707379
...get_thread_default returns NULL when the thread default is also the global
default, so this only shows up when running in a thread (eg g_task_run_in_thread)
This is a relic from long ago when we were trying to stage objects
before finally committing them all in one go in the pull code.
We're no longer doing that, so stop trying to make the directory.
This also fixes trying to use ostree as non-root to read the
root-owned repo, since we'd fail to create the pending dir.
For the cases where we can't hardlink, use at-relative walking of the
path where possible. We still don't have lsetxattrat, so we also need
to deal with pathnames, but that is now only for symlinks.
Again, the advantages of this are a lot less malloc() of pathnames in
ostree, and much less time spent traversing paths inside the kernel.
https://bugzilla.gnome.org/show_bug.cgi?id=707733
Nothing external uses it. We keep ostree_get_xattrs_for_file() public
because it's convenient for external consumers to get xattrs in
exactly the format we desire.
https://bugzilla.gnome.org/show_bug.cgi?id=707733
Do as many operations as we can using the original file descriptor
while we have it open, rather than writing, closing, then reopening.
This necessitated very explicitly special casing symbolic links,
mainly due to the lack of lsetxattrat().
https://bugzilla.gnome.org/show_bug.cgi?id=707733
Clean up how we deal with the uncompressed object cache; we now use
openat()/linkat() and such just like we do for the main objects/.
Use linkat() between the objects and the destination, if possible.
https://bugzilla.gnome.org/show_bug.cgi?id=707733
Instead, use OstreeRepoFile as a handle for the parent commit.
We need to add an accessor for the metadata checksum, as that
hasn't been exposed before.
https://bugzilla.gnome.org/show_bug.cgi?id=707727
We can't quite do it for bare repositories yet because we need to have
a way to go from struct stat -> GFileInfo, and that's buried in gio's
private GLocalFile class.
Just use openat() for locating variants, rather than doing the lstat()
+ open(). This also drops several malloc+object allocations from the
lookup path.
Add new internal API to both fstatat() and write a pathname for the
given object. Use it in commit, and also wrapped in the old
GFile-based API.
This is more efficient.
Rather than having separate write_ref calls, make clients start a
transaction, add some refs, and then commit it. While this doesn't
make it 100% atomic, it makes it easier for us to use an atomic
model, and it means we don't do as much I/O updating the summary
file and such.
https://bugzilla.gnome.org/show_bug.cgi?id=707644
An earlier version of this API acted like git in that some objects
would be staged in a temporary directory which would be then committed
in one go by moving files around. The API doesn't match most users
expectations though, as while the stage is nice as a high-level API
it isn't really suited for low-level APIs.
While the stage was removed, the APIs were never renamed. Rename
them now so that they match expectations.
https://bugzilla.gnome.org/show_bug.cgi?id=707644
This avoids repeatedly traversing the target pathname, and is just
more efficient.
Part of a prelude to using fd-relative API for the source object path
too.
Update libgsystem submodule for a bugfix.
This is both more efficient from a kernel perspective, and avoids us
calling gs_file_get_path_cached() on tmp_dir constantly, which
triggered another bug due to lack of locking.
It's now isolated almost entirely to ostree-core.c, except
ostree-repo.c needs to know how to create archive-z2 file headers. So
give it a private API for that.
See the new comment in the source; basically if we're fetching content
over http, then someone with the capability to MITM the network could
create a transient setuid binary on disk with arbitrary content. If
they also had a process running on the system (such as an application)
it could be escalated to root.
https://bugzilla.gnome.org/show_bug.cgi?id=707139
There's not a good reason to write small things such as repo/config to
the filesystem, only to read them back in again. Change the
non-partial API to just return a stream, then read it into a memory
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=707157
I think originally we had the .part/.done separation because we were
trying to support partial downloads of files like repo/config and
repo/refs.
But now that the http server configuration won't give us partial
results, we don't need to support caching those files between runs.
And thus, there's no reason to have the .part/.done and do the dance
with renaming them.
When fetching objects/ and other things that use _with_async, we
continue to use _append_to(), and if the returned range tells us we
have all the bytes, then we hand the full file over to the caller.
Don't attempt to shortcut in the case where the last run told us we
already have the object; the object fetcher code will not make a
request.
While we're here, also clean up use of GError and consistently use the
cancellable from the pending.
https://bugzilla.gnome.org/show_bug.cgi?id=707157
Extracting the code for parse_ostree_cmdline() and running it on some
test input (on RHEL6.4 glibc), I can reproduce the odd behavior from
getline() where it apparently returns the size of the default malloc
buffer in the size output, and some non-zero value.
This behavior would be OK except that it breaks the logic for
stripping off the trailing newline, which in turn breaks booting
because we return "ostree=foo\n".
This has worked so far in gnome-ostree because syslinux apparently
injects initrd=/path/to/initrd as a final kernel argment.
Anyways, we don't handle NUL characters here in /proc/cmdline, so
let's just call strlen () to be safe.
https://bugzilla.gnome.org/show_bug.cgi?id=707192
Behave similar to git when 'ostree commit' is run without
a --subject or --body. Bring up an editor. The first line becomes
the subject and following lines become the --body after an optional
blank line.
Use similar logic to git in determining EDITOR
https://bugzilla.gnome.org/show_bug.cgi?id=707063
Fold in fetch_uri to fetch_uri_utf8(), and rename the latter to
include _sync as a suffix, since it's synchronous.
Improve the status line to show when we're fetching a synchronous URI;
previously we just showed "Scanning metadata".
https://bugzilla.gnome.org/show_bug.cgi?id=707023
Use a consistent temporary filename to download uri's.
Check for downloaded files before fetching from uri.
Download to hash.part file, then copy/move to hash.done when complete.
Add argument support to setup_fake_remote_repo1 function.
Add test for pull resume.
To implement this, pass --force-range-requests into the trivial-httpd,
which will only serve half of the objects to clients at a time.
https://bugzilla.gnome.org/show_bug.cgi?id=706344
Pull the cleanup code to a helper function, and ensure we delete
leftover temporary files also when aborting a transaction. Mainly
this will happen if a local 'ostree commit' fails.
While we're here, also change it to use gs_shutil_rm_rf() which also
handles directories, should we start using those.
Reviewed-by: Jeremy Whiting <jpwhiting@kde.org>
It turns out every builtin (with one special exception) that takes a
repo argument did the same thing; let's just centralize it. The
special exception was "ostree init --repo=foo" where foo is expected
to *not* actually be a repo. In that case, simply skip the
ostree_repo_check() invocation.
https://bugzilla.gnome.org/show_bug.cgi?id=706762
We removed support for writing "related objects" from ostree commits
in ostree git c9b61cbfee because it just
didn't work out as an idea. This also removes the API and code from
"ostree pull".
Note there was no test suite coverage.
https://bugzilla.gnome.org/show_bug.cgi?id=706342
OSTree now supports multiple bootloader backends so
notify which bootloader configuration was detected.
https://bugzilla.gnome.org/show_bug.cgi?id=706548
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Currently, when deploying an OSTree that does not contain a
bootloader configuration it fails with the following message:
"No known bootloader configuration detected"
A bootloader configuration is not strictly necessary if the
bootloader used is able to parse /boot/loader/entries on boot.
So, failing to deploy seems to be a little harsh. It is better
to just not write the bootloader configuration if a previous
one was not found but still swap the bootversion.
https://bugzilla.gnome.org/show_bug.cgi?id=706477
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Before, we were writing the "bootversion", which is either 0 or 1, for
all entries. This is completely wrong; the idea of the "version"
field is to compare between entries.
Fix this by writing out the inverted index - internally, index 0 is
the *first* boot entry, so we give it the highest version number, and
index N is the last, so give it version 0.
Then fix the deployment sorting code to correctly reverse the version
number comparison, so we read back the right order.
In practice before this bug didn't matter because "normally" you only
have at most two deployments.
https://bugzilla.gnome.org/show_bug.cgi?id=706546
The way we recurse into subdirectories in parallel makes it far too
easy to hit up against the arbitrary Linux fd limit of 1024.
Since the fix here is about dropping parallelism, let's just go all
the way for now and make a plain old synchronous API =(
This does simplify both internal callers which wanted a sync API
anyways.
https://bugzilla.gnome.org/show_bug.cgi?id=706380
This patch adds support to generate files that
can be used by Universal Bootloader (U-Boot).
U-Boot allows to modify boards default boot commands by
reading and executing a bootscript file or importing a
plain text file that contains environment variables that
could parameterize the boot command or a bootscript.
OSTree generates a uEnv.txt file that contains booting
information that is taken from Boot Loader Specification
snippets files as defined in the new OSTree deployment model:
https://wiki.gnome.org/OSTree/DeploymentModel2
On deploy or upgrade an uEnv.txt env var file is created
in the path /boot/loader.${bootversion}/uEnv.txt. Also, a
/boot/uEnv.txt symbolic link to loader/uEnv.txt is created
so U-Boot can always import the file from a fixed path.
Since U-Boot does not support a menu to list a set of
Operative Systems, the most recent bootloader configuration
from the list is used.
To boot an OSTree using the generated uEnv.txt file, a
board has to parameterize its default boot command using the
following variables defined by OSTree:
${kernel_image}: path to the Linux kernel image
${ramdisk_image}: path to the initial ramdisk image
${bootargs}: parameters passed to the kernel command line
Alternatively, for boards that don't support this scheme,
a bootscript that overrides the default boot command can be used.
An example of such a bootscript could be:
setenv scriptaddr 40008000
setenv kernel_addr 0x40007000
setenv ramdisk_addr 0x42000000
ext2load mmc 0:1 ${scriptaddr} uEnv.txt
env import -t ${scriptaddr} ${filesize}
ext2load mmc 0:1 ${kernel_addr} ${kernel_image}
ext2load mmc 0:1 ${ramdisk_addr} ${ramdisk_image}
bootm ${kernel_addr} ${ramdisk_addr}
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=706370
ot-bootloader-syslinux.c has a join_lines() function that is rather
generic and can be used in other places. Let's add it as a helper
function.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=706370
We'll always have "bare" mode for keeping files-as-hardlinks as root.
But "archive" was my second attempt at a format for non-root file
storage, used by the gnome-ostree buildsystem which runs as non-root.
It was really handy to have a "tar" like mode where I can create
tarballs as a user, that contain files owned by root for example.
The "archive" mode stored content files as two pieces in the
filesystem; ".file" contained metadata, and ".filecontent" was the
actual content, uncompressed. The nice thing about this was that to
check out a tree as non-root, you could just hardlink into the repo.
However, archive was fairly bad for serving via HTTP; it required
*two* HTTP requests per content object, greatly magnifing the already
inefficient fetch process. So "archive-z2" was introduced.
To allow gnome-ostree to still check out trees as a user, the
"uncompressed-object-cache" was introduced, and that's how things have
been working for a while.
So we should just be able to kill this code. Specifically note just
how much better the stage_object() function became.
https://bugzilla.gnome.org/show_bug.cgi?id=706057
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
We have APIs to load metadata as variants, and files as parsed
content/info/xattrs, but for some cases such as static deltas, all we
want is to operate on all objects in their canonical representation.
https://bugzilla.gnome.org/show_bug.cgi?id=706031
We used to have a version of this, but since I'm trying to use
GBytes more, this became a more common operation, and it's annoying
to type out the whole G_VARIANT_TYPE ("ay") each time, and pass
TRUE for trusted.
https://bugzilla.gnome.org/show_bug.cgi?id=706031
This will be used to test resuming interrupted downloads for
ostree-pull.
With this option, if a whole file is asked for, only half of the file
is given. Then the client should retry with a range request, and
we'll give them the other half.
https://bugzilla.gnome.org/show_bug.cgi?id=705925
If we pass XATTR_REPLACE then the attribute must already exist, which
is not our intent. Passing zero creates the attribute if necessary,
or replaces it when it already exists.
https://bugzilla.gnome.org/show_bug.cgi?id=705893
* Specifying global options after the command for a more natural:
# ostree commit --repo=/path/to/repo ...
* Support asking for --help without --repo
# ostree commit --help
* Support short form of -h
* Support specifying --repo without equals sign
# ostree --repo /path/to/repo commit ...
* Support global --help and -h
# ostree --help
* Ditto for ostree admin sub commands
* Removed some leaky code
https://bugzilla.gnome.org/show_bug.cgi?id=705903
While the actual commit object format is presently the same, for a
number of reasons we'd like to change it fairly radically. Among
other things, we need to drop our a{sv} types in objects, to protect
against GVariant changing format.
Since now gnome-ostree now longer uses related objects, and nothing
ever used metadata, just drop them both.
If the admin encounters corruption and does:
$ ostree admin fsck --delete
We want them to be able to recover the objects easily from the
network; with this patch, they do:
$ ln -s dummyvalue /ostree/repo/transaction
$ ostree refs --delete remotename:branchname
$ ostree pull remotename
This patch avoids the need for the refs --delete; we might as well
force scan the commit, and with this patch we still print that it
changed.
We may revive this later, but commits in their current form aren't
very useful for humans to read, so it doesn't make sense to have a
tool to show a history of useless stuff.
More interesting things are diffs between commits, object statistics,
etc.
Otherwise it's really easy to keep accumulating deployments. Also, we
may want to run this after rebooting, so we're back down to one
operating system.
And disable devino scan by default. For the gnome-ostree build case,
our commits are from "make install DESTDIR=", so they won't be
hardlinks into the repo. In that case, particularly as the repository
size grows, the cost of building up the devino -> checksum mapping
becomes a problem.
The compose step will use this option though.
While the first was useful way back in the day when we were importing
Debian bits and /sbin/init was expecting to find /dev/.initctl as a
named pipe, that's no longer an issue with systemd since it uses
dynamic Unix sockets.
Likewise, character and block devices in /dev are now dynamically
created by the devtmpfs from the kernel.
Less complexity and code here if we just support directories, regular
files, and symbolic links.
Calling it "cleanup" is better since it does more than repo pruning.
We were also doing a prune twice; ot_admin_cleanup() already does one,
so drop the bits to do it in cleanup.c.
Colin Walters
Roddy Shuler
Daniel Narvaez
Jeremy Whiting
Jasper St. Pierre
Sjoerd Simons
Vivek Dasmohapatra
Tobias Hunger
Stef Walter
Jeremy Whiting
Javier Martinez Canillas
Sjoerd Simons