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.