My first TUF repo

This tutorial will show you how to:

Create development fixtures

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.

Run basic Rugged commands

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.

Next Steps

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.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Rugged TUF Server is a trademark of Consensus Enterprises.