This tutorial will show you how to:
In order to explore Rugged’s functionality, it’s easiest to start by creating some sample content:
$ make fixtures
You can then review the generated fixtures with:
$ tree fixtures
In particular, the TUF metadata Rugged generates can be found at fixtures/tuf_repo/metadata
.
Finally, let’s run a few Rugged commands to see what’s going on.
We’ve added a DDEV command that delegates calls to rugged
into the “packaging pipeline” container. For convenience, it also handles calling rugged
, via sudo
as the ‘rugged’ user.
ddev rugged
We can now see the various sub-commands that are available. Next, let’s see what’s in the logs:
ddev rugged logs
This prints the last 10 lines of the logs of each of the Rugged workers. Many commands support a --worker
option, that will show just the results from a single worker.
Let’s try that option out when we look at the status of the repo:
ddev rugged status --worker=targets-worker
This display all relevant information about the state of the repo from the target worker’s perspective.
Let’s try again, but look at the timestamp worker’s status
ddev rugged status --worker=timestamp-worker
One difference worth noting between these is which role has the “Signing” capability. Each worker performs a specific role withing the TUF system. With one important exception (the root worker), each will only have access to a single signing (ie. private) key. This is a key aspect of the TUF security model.
We suggest that you check out the other tutorials and how-to guides next.
Alternatively, you can also read more background information about how and why Rugged operates the way that it does.