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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This will allow to copy arbitrary files into the rootfs, specifying something like:
"add-files": [["service.template", "/exports/service.template"],
["config.json.template", "/exports/config.json.template"]]
It is quite useful when building a container image.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #253
Approved by: cgwalters
If one does `rpm-ostree foo --bar`, one would expect to see
`Unknown subcommand foo`, not `Unknown option --bar`.
Closes: #267Closes: #270
Approved by: jlebon
Otherwise we `exit(0)`, but trip an internal warning.
We have so much copy/paste going on here, but let's fix the
bug first.
Closes: #261Closes: #262
Approved by: giuseppe
Because `hif_source_get_location()` is actually a reference to the
upstream repo, we shouldn't create a cache directory there.
This is just a two line fix, but I changed some things so that we keep
track of the number of local packages, in order to make the "Need to
download" print accurate.
We still need to add them (confusingly) to the `packages_to_download`
because that's also used for the container path which imports them.
Closes: #255Closes: #256
Approved by: jlebon
It's not really baked, totally undocumented etc. Let's leave it in as
a tech demonstration for people who saw my Devconf.cz talk, but that's
it for now.
Pull request: #248
Approved by: jlebon
The fact that we didn't notice this is a testament to the state of
testing =(
I think I want to change the container build path to also only
grab /usr and /etc rather than having the paths be different,
but for now - the quick fix.
Pull request: #243
Approved by: jlebon
I was tracking another regression where we seem to have lost
`/usr/etc` contents which manifested as `Labeling with... (null)`
which was clearly wrong.
Now this change actually impacts the test suite - we now (again IMO
correctly) error out if `selinux: true`. The `no-selinux-tag` test
no longer makes sense, so delete it.
We do need more "real" tests that use selinux on and off.
Pull request: #243
Approved by: jlebon
The new context methods recently added for unprivileged infrastructure
would set the ostreerepo member when calling new_unprivileged(). Since
here we will be using the sysroot repo, we need the ability to set the
repo. Just add a new set function for now, maybe move it into
new_system() later.
Also, make sure we dereference the repo on finalize.
Pull request: #240
Approved by: cgwalters
There will be cases where we don't actually want to tag a ref on the
final assembled commit. This will be true for package layering.
Pull request: #240
Approved by: cgwalters
We allow the "repos" key to be missing, which just means that we let
libhif do its job, i.e. automatically use the repos in repodir that are
enabled.
We still do a check in rpmostree_context_setup() to make sure that at
least one repo is functional.
Pull request: #240
Approved by: cgwalters
It's expected to be able to switch to something different when
rebasing, even if the current origin has unconfigured-state.
Closes#232
Pull request: #238
Approved by: jlebon
libgsystem has long been deprecated, so this is a small step for man,
and not really a gigantic leap at all for anyone but hey, at least I
changed something in git today.
While I was debugging the tests, I wanted to run the daemon
interactively under gdb but still on the session. In our previous
logic this was only possible if we were exec'd by dbus-daemon which
made attaching gdb annoying.
Let's honor the environment variable consistently on client and
server.
This was a semantic change could potentially impact a lot of users who
weren't aware of the new '77 == unchanged' status and would treat it
as an error.
We retain the 77 for `--check` as I feel it's likely fewer people were
scripting that, and the ones that were would more quickly adapt to the
change.
As part of this, change the logic for detecting a change to be more
explicit by comparing the defaults. I think this will fix a potential
bug where we could get a property change notification even if nothing
changed.
Now that the internal reading methods operate on the mainloop, and we
know there can only be one write transaction at a time, it should be
safe to drop the internal mutexes (and multithreading).
Updates to the `OstreeSysroot` instance and DBus API all happen off
the mainloop now. The write transactions now use a separate
`OstreeSysroot` instance, and do not perform any changes to process
state on their own. We always reload state from disk.
I think this is a lot simpler to reason about from a correctness point
of view, at a likely negligble loss in performance for read
transactions.
I'd like to move towards a model where internal worker threads don't
touch the "main context data", i.e. we only use message passing (via
main contexts). This means we wouldn't use a mutex.
I find this model to be significantly simpler to reason about.
Every transaction runs in a thread now, and there's no real drawback
to consistently creating a main context to go with it always. Most
of the transaction types now do a pull, which needs it.
Now that we have `ostree_sysroot_load_if_changed()`, we know more
precisely (and cheaply) when things change. Use inotify to detect
changes as before, but we don't need a timeout because all we do is
call `fstatat()` which is basically free; the inode is going to be in
memory.
This will hopefully help with
https://github.com/projectatomic/rpm-ostree/issues/220
but more investigation is needed.
We were loading the list of osnames by walking the FS, but it's a lot
simpler to just extract the set of known osnames from the deployment
array.
This is part of an effort to unify the "sync cached state with disk"
code in order to address race conditions.
We can't rely on the the GLib hash functions not changing (or being
stable across host systems). Basically here we have a "stringified"
deployment...it might be simpler to just declare this stable.
For the columns that can vary in width, check that the minimum width of
the column is at least the length of the column header. Otherwise, we
can run in a situation where some columns are stuck to each other. The
trivial strlen() should be optimized to a constant by the compiler.
There are many reasons why the daemon may not be able to start up. An
initialization error doesn't/shouldn't reflect a programming mistake,
but instead a runtime issue in the environment.
Thus, if we fail to start the daemon, we shouldn't use g_error(), which
dumps core. We should instead print the GError and clean up as nicely as
we can.
Resolves https://github.com/projectatomic/rpm-ostree/issues/194.
Right now we're doing the /etc -> /usr/etc inside the RPM import, but
we might as well do the /usr/local bits in both. Also, use
/usr/share/rpm by default for treecompose too so that is unified.
Other things like systemd unit files and kernel handling are only
going to be used for host side composes.
I debated config file formats a lot. JSON is fairly awkward for
humans to write, and really painful to parse from C. YAML is nice,
but also painful from C.
Both are fairly overpowered for what we really need. Keyfiles
(desktop spec, `GKeyFile`) have a lot of limitations, but at least
it's used by systemd and `.desktop` files, and we already have a
parser.
We still parse the JSON treefiles, but internally convert them to
`GKeyFile` (which is in turn converted to `GVariant` for a canonical
form).
This is just a tech demo. Example usage:
```
mkdir -p ~/.cache/rpmostree-containers
cd ~/.cache/rpmostree-containers
rpm-ostree container init
cp /etc/yum.repos.d/CentOS-Core.repo rpmmd.repos.d
rpm-ostree container assemble bash
rpm-ostree container assemble httpd
```
This is in preparation for `rpm-ostree container`, which handles
unpacking RPMs as non-root.
At the moment, I'm copying code in from both ostree's libarchive bits
(fixable...may need to export some utility functions) and some
functions from libhif (harder, see:
http://lists.rpm.org/pipermail/rpm-ecosystem/2016-January/000297.html )
There's lots more cleanup to do here, but I don't want to block on the
resolution of the libhif changes.
This is part of taking over from librpm. The most important high
level goal is fully unprivilged operation.
Right now we're basically starting to do what
http://libguestfs.org/supermin.1.html does, except in C, and
faster.
There's no reason that `compose tree` should require privileges.
However right now, things like `%post` scripts will want to run in the
target root - so we'd have to require `linux-user-chroot`.
Regardless of unprivileged operation though, another major thing we
can do is use our control over the unpacking process to do a lot more
sophisticated caching. We can build up a precise mapping of (rpm
ENVR, file path, selinux label) -> object and avoid rechecksumming
each time.
And even for files that aren't known, we can parallelize commit with
unpacking, etc. (Ok assuming treecompose-post won't mutate anything).
I'd like to experiment with different things that end up
reusing chunks of the rpm-ostree internals, such as libhif, the
helpers we already have around RPM, etc.
In this particular case I'm experimenting with unpacking/committing
RPM packages as non-root. Eventually most of this should end up as
internal private shared library, but it's convenient to have an
ABI-unstable and hidden "internals" command to run things directly.
This commit though just adds the scaffolding for "internals".
As we start to do more package things, extract common helper functions
around HifContext * that by default operates on the system root.
Some of these bits should go in libhif, but the immediate plan is to
iterate here, then push downwards later.
Besides porting GFile -> fd, I specifically want it to operate in an
append mode for package layering. Then given an existing tree, we
ensure we're not deleting the underlying tree's autovar files.
Encountered a couple crash scenarios:
1) A commit with an invalid timestamp trips an assertion. Instead
show the timestamp as "invalid".
2) If a deployed commit is unsigned, the daemon will not include a
"signatures" array in the deployment's GVariant representation.
The logic for --pretty was assuming the "signatures" array is
always present.
Determines a revision argument to either be a SHA256 checksum or a version
metadata value.
The revision string may have a "revision=" prefix to denote a SHA256
checksum, or a "version=" prefix to denote a version metadata value. If
the revision string lacks either prefix, the function attempts to infer
the type of revision. The prefixes are case-insensitive.
rpm-ostree upgrade --preview - Just preview package differences,
like deploy --preview
rpm-ostree upgrade --check - Just check if an upgrade is available
In both cases, the exit codes are 0 (upgrade available), 77 (no upgrade
available) and 1 (error).
The --check-diff option still works but is deprecated and not shown in
the --help option listing.
Don't remember why we're not using the daemon for this, but I already
went to the trouble of writing rpmostree_print_package_diffs() for the
"deploy" command. Use it here as well.
rpmostreed_commit_generate_cached_details_variant() returns NULL if the
origin checksum of an OstreeDeployment matches the checksum of a refspec,
which may also be the OstreeDeployment's origin.
I don't understand the reasoning for that, especially since none of the
callers are prepared to deal with a NULL return. Nor is there a comment,
so remove the check.
This was making the daemon crash on
rpm-ostree deploy --preview <current-deployment-checksum>
which should just indicate no package differences.
Deploy method locks the deployment at a particular commit by adding an
"override-commit" line to the origin file.
Upgrade method must undo the override so we always upgrade to the latest
available commit.
Deploy(revision) pulls and deploys a particular revision on the
branch of the currently booted deployment. The revision can be
expressed as a SHA256 checksum or as a version metadata value.
Similar to rpmostreed_repo_lookup_version(), except without pulling from
a remote repository. It traverses whatever commits are available in the
local repository.
rpmostreed_repo_pull_ancestry() downloads an ancestry of commit objects
starting from a given refspec. An optional visitor function is called
for each commit object. The visitor function can stop the recursion,
such as when looking for a particular commit.
rpmostreed_repo_lookup_version() builds on this by supplying a visitor
function that examines commit metadata for a particular version value.
When the version value is found, the commit's checksum is returned to
the caller.
Change the command callback return type to integer, so commands can
return a custom exit status. Usually it should be EXIT_SUCCESS (0)
or EXIT_FAILURE (1).
This should help to generate the same initrd when the files didn't
change.
Newer versions of gzip (or pigz when available) can generate rsync
friendly files and if present, Dracut already takes advantage of it.
Also use --reproducible, to instruct Dracut to generate CPIO
reproducible files. It is required a version of GNU CPIO that
has support for it.
Check that Dracut has --reproducible in its --help output before
setting it.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Otherwise the `umount()` will always fail. This hasn't been a problem
so far while running in a external container (docker/systemd-nspawn),
but is when running in `mock` because it doesn't set its namespace to
be private.
This should help Fedora's Bodhi, which uses rpm-ostree inside mock.
Allows clients to see version, timestamp
and other detailed information along with
the rpm diffs for cached updates and rebases.
This will be used by the Cockpit interface.
Adds a CachedUpdate property that allows clients
to see version, timestamp and other detailed
information for pending updates. Additionally
changes to this property signal clients that a
new rpm-diff can be fetched with GetCachedUpdateRpmDiff.
This will be used by the Cockpit interface.
Various OS "diff" methods can run concurrently with whatever else is
going on since they don't have to obtain the system root lock.
Just to make sure there's no conflicts when writing deployments or
downloading RPM package details, use an internal reader/writer lock
to protect the critical sections of upgrade, rebase, rollback, etc.
Create and load a new OstreeSysroot and OstreeRepo instance as needed.
This ensures its internal state is up-to-date, since several ostree
commands can alter stored state without the daemon's knowledge.
I would prefer keeping persistent instances if these issues can be
addressed, as it would eliminate some inconvenient error handling.
But this way is safer for now.
