comtrya / comtrya

Configuration Management for Localhost / dotfiles

Comtrya

This is better, yes?

---

---

Want to learn how to use Comtrya? Check the docs.

Comtrya now also has documentation in the repository located in the docs/ folder. In order to use it, please install mdbook using cargo install mdbook. Navigate to the docs/ directory and run mdbook serve. The documentation will be available through your web browser usually on localhost:3000.

---

About

Comtrya is a tool to help provision a fresh OS with the packages and configuration (dotfiles) you need to become productive again.

I'm a serial OS installer, I wipe the OS on my machines every, approx, 30 days. I've primarily relied on SaltStack to automate this, but I've grown frustrated with the mismatch between configuration management and personal provisioning.

I've also tried Ansible, Chef, Puppet, mgmt, and probably anything else you're about to suggest; they all have a flaw that makes it too cumbersome to adopt for the trivial use-case.

Installing

You'll find binaries over on the releases page.

If you're not feeling risk-averse, you can use this one-liner:

curl -fsSL https://get.comtrya.dev | sh

or specify VERSION=vx.x.x to pin to a release version

VERSION=v0.8.8 curl -fsSL https://get.comtrya.dev | sh

If this doesn't work for your OS and architecture, please open an issue and we'll do our best to support it.

Usage

# Run all manifests within your current directory
comtrya apply

# --manifests, or -m, will run a subset of your manifests
comtrya apply -m one,two,three

# Run all manifests within a specified directory
comtrya -d ./manifests apply

What's Next?

You should take a look at the issues page to see what's available to contribute. Below is a short list of the major features that are upcoming.

Better Output

Providing a --quiet or --summary option that restricts the output to the run time

Comtrya finished in 12.3s

Installed Packages: 12
Provisioned Files: 34

Async DAG

We're using petgraph to build out the graph, but we're not traversing it in a way that will allow us to concurrently execute manifests at the same depth. This is something I wish to sort out pretty soon.

Package Provider Enhancements

Currently, we execute arbitrary packager install commands. The provider spec should be enriched to support:

• List refresh
• Upgrades
• Version pinning

Integration tests

We are a bit light on tests at the moment, but we have started introducing some helpful plumbing in tests.

comtrya's Issues

New Package Provider: Pacman / Yay

feature: add snap provider

Add provider for snapcraft documentation

New `run_command` helper is leaking output

It's inheritting stdin, and friends, which it should only be doing for the sudo -v

Operating System Contexts

Related to #99

Output and logging

If comtrya is applying the example manifest for command.run this was the output for version 0.6.1:

hi
root
  INFO manifest_run{manifest="run"}: Completed

As of version 0.6.2 this is the output:

  INFO manifest_run{manifest="run"}: RunCommand with privileged false: echo hi
  INFO manifest_run{manifest="run"}: RunCommand with privileged false: whoami 
  INFO manifest_run{manifest="run"}: Completed

While it's definitely an improvement to see what was actually done and not just the result, especially in the whoami example the result is very much relevant. I think that at least in verbose mode it would make sense to have something like this instead:

  INFO manifest_run{manifest="run"}: RunCommand with privileged false: echo hi
  DEBUG Command output was: "hi"
  INFO manifest_run{manifest="run"}: RunCommand with privileged false: whoami
  DEBUG Command output was: "root"
  INFO manifest_run{manifest="run"}: Completed

It might also make sense to allow for logging to a file instead of only printing to stdout. Yes, it can be redirected and yes, you can use tee to both see it and have it written to a file. However for the log files it would make sense to write just text to them and not the color codes for example. Also prefixing everything with a timestamp would be helpful for taking a look at what actually happened should you figure out later that something went sideways.

This will probably be even more useful once it can be configured in Comtrya.yaml instead of having to be specified with each command line.

add update flag to package.install

given this action:

actions:
  - action: package.install
    name: git

running the module will install git as expected the first time. with a brew provider it will fail if git has a version bump on a subsequent apply.

 ERROR manifest_run{manifest="git"}:package.install{provider="Homebrew"}: Error: git 2.30.2 is already installed
To upgrade to 2.31.0, run:
  brew upgrade git

 ERROR manifest_run{manifest="git"}: Failed to install git
 ERROR manifest_run{manifest="git"}: Failed

comtrya should handle this gracefully in the default case, because git is installed.

it would be useful to have a flag or an alternative action to either install or update the package.
if the package is installed and latest, no actions are taken. If the package is installed and outdated, the package is updated. if the package isn't installed, the package is installed.

options:

actions:
  - action: package.latest
    name: git

or

actions:
  - action: package.install
    update: true
    name: git

New Action: macOS Defaults

https://macos-defaults.com/

Aptitude Bootstrap Not Working

New Context: Variables

We should allow the user to provide a Comtrya configuration file that allows them to add their own values into the Context tree.

File Actions: Templating should be false by default

Rendering a file and interpolating contexts should be the configured option, with the default being simply to work with whatever file is provided by the repository.

Allow overwiting the `files` directory

Problem

for actions like file.copy and file.link allow overwriting the default files directory that is required.

Reasoning

if for instance, you are migrating from something like stow the file structure of your dotfiles is set out with folders like bash or vim. Comtrya currently requires you to change the structure for your files to be in the structure of vim/files and bash/files which does not allow for a lot of flexibility in how you want to structure your dotfiles if you could for instance overwrite this variable at the action level it would allow a lot of people to keep their dotfiles structure and still use Comtrya

example:

actions:
- action: file.link
   # Overwrite where to look for file 
   base: bash
   from: .bashrc
   to: {{ user.home_dir }}

New Feature: Dry Run

Allow for a —dry-run flag to be provided which will show which manifests will be executed and which packages and files each will provision.

New Action: Create Directories

Manifests in subfolders should keep the folder name in their identifier

Right now if I have a manifest in a subfolder e.g. formulas/1password.yml the folder is either ignored or stripped away by manifest_load. It is confusing because the depends will expect only the filename while we are used to specifying the path for an import.

Also, if I have a manifest with the same name in another folder it looks like the second manifest to be loaded silently replaces the first.

Add ability to encrypt/decrypt files

This is a feature request:

Since I'm using a lot of different computers, it would really help me to add the ability to encrypt/decrypt files.
So I can publish them in a public Git repo.

For example I'm using bastion hosts in my ~/.ssh/config file, but I don't want to be those public (the IP addresses):

Host bastion
  HostName 10.10.11.1
  User bastion
  IdentityFile ~/.ssh/bastion

In my example I used an internal IP Address, but normally these are public ip addresses.

I know that Ansible Vault is using AES256 to encrypt/decrypt files, I'm not sure if something like this is working in Rust.

So, maybe add a "Comtrya vault?", with the ability to:

• Encrypt files (with a comtrya vault command)
• Decrypt files when running comtrya
• Ability to add a vault_key in the comtrya configuration? For example ~/.comtry/vault_password.txt, so we don't need to type the password everytime we're running the comtrya command.
• Check the vault file for "world" persmissions, for example only allow it when it's chmod 600? To prevent data leaks :).

Remote Manifest Extensions

We should support the docker image build Git syntax that allows specifying a revision and directory within the repository.

Such as:

Build Syntax Suffix	Commit Used	Build Context Used
myrepo.git	refs/heads/master	/
myrepo.git#mytag	refs/tags/mytag	/
myrepo.git#mybranch	refs/heads/mybranch	/
myrepo.git#pull/42/head	refs/pull/42/head	/
myrepo.git#:myfolder	refs/heads/master	/myfolder
myrepo.git#master:myfolder	refs/heads/master	/myfolder
myrepo.git#mytag:myfolder	refs/tags/mytag	/myfolder
myrepo.git#mybranch:myfolder	refs/heads/mybranch	/myfolder

Need a way to restrict package providers to supported platforms

add a version (or --version)

Suggestion- seems you already provide this in the help but for debugging wouldnt a --version or -v option make sense?

Allow Variants on any Action

We allow the variant syntax on package actions to handle the name, or provider, changing across different operating systems.

The same could be used for files and commands, where config locations or even commands differ.

Bug: can't rerun file.link

Bug Report

Steps to reproduce

1. Add a file.link action
2. Apply the manifest (by running comtrya)
3. Observe that symlink exists
4. Apply the manifest again
5. Get an error

Expected behaviour

• if the correct symlink already exists, do nothing
• if the file exists and is not the correct symlink, emit an error (warning?)

Option to use sudo for package install action (ubuntu OS)

As a non-root user, when executing a manifest to install packages, comtrya reports that package was installed successfully even though the package was not actually installed.

It would be good to have an option like require_sudo: true for package install actions (maybe globally on the manifest or per action).

Machine details:

• OS: Ubuntu 20.04 LTS
• ubuntu user able to sudo without password

Test Output:

ubuntu@ip-192-168-21-173:~/comtrya/dev$ comtrya -vv docker
 TRACE manifest_directory="/home/ubuntu/comtrya/dev/docker" manifests="" Comtrya execution started
 DEBUG OS Detected OS="Ubuntu"
 TRACE Building Contexts
 DEBUG context="user" key="name" value="Ubuntu"
 DEBUG context="user" key="username" value="ubuntu"
 DEBUG context="user" key="home_dir" value="/home/ubuntu"
 DEBUG context="user" key="config_dir" value="/home/ubuntu/.config"
 TRACE manifest_load{manifest="main.yaml"}: manifest="main.yaml"
 TRACE manifest_load{manifest="main.yaml"}: absolute_path="/home/ubuntu/comtrya/dev/docker/main.yaml"
 TRACE manifest_load{manifest="main.yaml"}: template="actions:\n  - action: package.install\n    name: docker\n\n"
 TRACE manifest_load{manifest="main.yaml"}: rendered="actions:\n  - action: package.install\n    name: docker\n\n"
 TRACE manifest_load{manifest="main.yaml"}: Registered Manifest manifest="docker"
 DEBUG manifests=""
  INFO manifest_run{manifest="docker"}:package.install{provider="Aptitude"}: Package Installed packages="docker"
 DEBUG manifest_run{manifest="docker"}: Packages installed successfully
  INFO manifest_run{manifest="docker"}: Completed

ubuntu@ip-192-168-21-173:~/comtrya/dev$ which docker
ubuntu@ip-192-168-21-173:~/comtrya/dev$ docker

Command 'docker' not found, but can be installed with:

sudo snap install docker     # version 19.03.13, or
sudo apt  install docker.io  # version 19.03.8-0ubuntu1.20.04.1

See 'snap info docker' for additional versions

New Action: Install GitHub Release Binaries

docs: integration with cloud-init, examples

It should be possible to use cloud-init to do just the bare minimum of bootstrapping to get comtrya loaded and then have comtrya continue on its merry way to do the rest of a user bootstrapping process.

For this, no changes to the comtrya code should be needed, but some docs and examples would help.

Document Variant Syntax

Ubuntu 20.04 install fails "Not: not found" after "Download complete" message.

New install on a Ubuntu 20.04 machine fails

root@bastion-01:~# curl -fsSL https://get.comtrya.dev | sh
x86_64
Downloading package https://github.com/rawkode/comtrya/releases/download/latest/comtrya-x86_64-unknown-linux-gnu as /tmp/comtrya-x86_64-unknown-linux-gnu
Download complete.

Running with sufficient permissions to attempt to move comtrya to /usr/local/bin
New version of comtrya installed to /usr/local/bin
/usr/local/bin/comtrya: 1: Not: not found

and it appears that the /tmp directory does not include /tmp/comtrya-x86_64-unknown-linux-gnu.

The contents of /usr/local/bin/comtrya when I'm done is

Not Found

Feature: file.copy should support downloads

It's pretty common to want to download software (or maybe config) from http, even ftp.
wget can be run from command.run, but you have to dump it in /tmp etc etc.
It feels nice to model this by supporting http etc URL schemes in file.copy (file:// can be the default in the case of no scheme)

Plugin and Hooks arquitechiture

Looks like you already have a good modularization in Comtrya. It would be nice if it supported plugins. Actually, since I don't know Rust and had some issues with using Comtrya to run the manifests I almost created a clone of it in Typescript hahaha. I could help with the plugin architecture design if you give me some pointers on the current architecture.

Here are some extension points I think could be created if you decide to add plugin support:

• Custom Actions
• Custom Contexts
• Custom Providers
• Custom top-level "things" (not sure what you would call depends and actions at the top of the yml file)

If you want to go further and turn Comtrya into a framework, you could also add extension points to:

• Manifest parser
  which would allow creating parsers for other languages. I think JSON can be useful in certain contexts
• Cli commands
  I created a script called pack_stuff that could became a plugin. It exports PPAs, repositories and user installed packages list that can then be read by the move_in.yml manifest in the new system
• Hooks for many points of the process, e.g.:
  • on_start - that would allow setting up logging
  • before_action - could allow me to define a rule that asks for confirmation before running and cancel execution
  • on_dependency_require - could enable custom dependency processing like downloading a yml from github and returning the path to the local file

Anyways, these are just examples. The point is that with plugins and hooks you don't have to implement most of the feature requests

Feature: run commands in an arbitrary git clone

Not all software installs nicely (via a package manager, or with go install / cargo install). I often find myself stringing together lots of command.run to:

• clone a repo, to a temp location
• cd into it
• run commands (make build && sudo make install kinda stuff)
• tidy up the clone.

It would be great to have an action like

- action: command.run:
  - command: make
  - args: [ install ]
  - inGit:
    - repo: https://github.com/mt-inside/annoying-package
    - ref: v1.2.3

Terraform like state management to add, update and destroy(remove) packages, files etc.

Comtrya is a promising project, I have faced similar problem in the past and mostly used shell scripts or Ansible - and always wonder if a tool can be built to have Terraform like semantics.

In the cloud world I like Terraform, mainly because one can add, update or destroy resources declaratively. I was wondering if same concept can be applied to this project - for OS provisioning - that would mean, the project will need to have a 'state' to reconcile configuration files with current state of the OS to determine whether to add, update or destory (remove) existing packages, files, and anything to manage OS.

The workflow would be very similar to Terraform, for example:

• comtrya plan (this could act as dry run)
• comtrya apply

An alternative I could think is building a custom Terraform provider which does local OS provisioning. I thought to share the overall idea, not sure if this aligns with overall goal of the project - but I'm looking forward to hearing your thoughts, what do you think?

Fix Typo in Label

There is an typo in the label Compnent::Contexts.
I think it should be spelled Component::Contexts

😉

Feature: openSUSE/zypper support

Would be nice to support the zypper package manager.

New output format enhancement

I'd like to propose a new output format for 2 reasons:

1. I understand why the output is how it is now but I feel the info I really want to keep an eye on (specially if I'm learning Comtrya is buried under a lot of noise.
2. When running manifests it is hard to tell if things worked or not. I was actually going to file an issue for getting stdout/stderr streamed live to the console and I just found out that it is if I use -vv (unless I misunderstood what I've read)

Here is what we get now:

  INFO manifest_run{manifest="hello"}: RunCommand with privileged false: echo hello, $(whoami)
  INFO manifest_run{manifest="hello"}: RunCommand with privileged true: echo $(sudo whoami) says hi
  INFO manifest_run{manifest="hello"}: Completed

As newbie to Comtrya, what I would like to see when running manifests is something like:

  [hello::command.run] echo hello
    hello, svallory
    done!
  [hello::command.run] echo $(sudo whoami) says hi
    root says hi
    done!
  [run] Completed!

If there's output to stderr I think it should appear in full and red! But the stdout could be a rolling tail of the last 10, 20 or n lines.

Default Behaviour Should Be Help

Everyone that has tried comtrya has complained about ./comtrya recursively searching their home directory 😅

New Action: Service Management

Enable / Disable / Start / Stop services on macOS, Linux, and Windows

File symlinking

Is this a feature request or a bug report?

Feature request

Describe the feature

It should be possible to symlink files with Comtrya. Preferably, this would be its own action, distinct from copying. Proposed syntax is similar to copy:

actions:
  - action: file.symlink
    from: gitconfig
    to: /Users/rawkode/gitconfig

Alternatively, we could make it file.link with symbolic being an option (default true).

Feature: redirect stdin and stdout of command.run

I have a lot of command.run actions which set up shell completion, eg running just --completions bash > ~/.completion.d/just
This is possible with command.run, but it's a bit messy.

command: sh
args:
  - -c
  - 'foo > bar'

It'd be great to have an argument to command.run eg

command: just
args:
  - --completions
  - bash
redirects:
  stdout: ~/.completions.d/rust

What do you think?

Feature: various local "install" support

I end up performing certain sets of actions together, eg

• copy a compiled binary to a system path, and strip it (some versions of unix install do this)
• copy/template a systemd unit to the right place, systemctl enable, systemctl start

I know we don't want to be a massive complex system, but it'd be nice to have first-class support for things like this, eg

- action: install.systemd_unit
  from: foo.service
  type: <system/user> # copies to /etc/systemd/system or ~/.config/systemd/user
  template: true

New Package Provider - WinGet

Publish via homebrew

It seems fairly doable https://federicoterzi.com/blog/how-to-publish-your-rust-project-on-homebrew/

Stow-like recursive symlinking

Given this directory, with stow I can run stow nvim from the root of my dot files repo to recursively symlink all the files resulting in ~/.config/nvim/{coc-config.vim,coc-settings.json,init.vim} existing.

I see that file.symlink was implemented (side note: looks like it didn't make the readme yet. I can PR that.). Would this behavior be more aligned to a directory.link? Or maybe an option on the directory.copy action?

Remote Manifests

Manifests shouldn't have to be on the local machine. However, this will require Git installed

Manifest Spec: Restrict to Context

Only run a manifest if it meets the criterion, which can match the context tree.

'chmod' option in file.copy

Motiviation: I have a set of little shell scripts that I want to bring down and install. Successful completion of the installation involves setting the execute bit with chmod. In some cases you might also want to install a file, like one that holds a secret, as something other than world-readable.

Suggested concrete syntax:

actions:
  - name: setup-tailscale-ubuntu-focal
   action: file.copy
   from: bin/setup-tailscale-ubuntu-focal
   to: /root/.bin/setup-tailscale-ubuntu-focal
   chmod: "700"
   template: false

Alternatives considered: This is a workaround for #35 where I might be able to install everything with the 'Aptitude' driver. The more general case of chmod is a little bit of flexibility to make things just so. Even without the execute bit I can do this bootstrapping phase with sh -x so not all is lost.

[Noted: updated reference syntax to reflect quoting necessary, because that integer is really an octal value]

dry-run shows error for actions on files downloaded in previous steps

Not sure how you would fix this (maybe with a fake filesystem?), but it's confusing to see an error in --dry-run and not when actually running the manifest. Here's an example:

svallory@boomerang:~/.dotfiles$ ./bcomtrya ./manifests/formulas -m vscode --dry-run
  INFO manifest_run{manifest="vscode"}: Step: HttpDownload from https://code.visualstudio.com/sha/download?build=stable&os=linux-deb-x64 to ./tmp/vscode.deb (Not printing initializers and finalizers yet)
 ERROR manifest_run{manifest="vscode"}: Couldn't get metadata for ./tmp/vscode.deb, rejecting atom: No such file or directory (os error 2)
  INFO manifest_run{manifest="vscode"}: Step: RunCommand with privileged true: apt install ./vscode.deb (Not printing initializers and finalizers yet)

New Action: Git Clone

install: Ubuntu 16 complains about GLIBC_2.25 version

emv@bastion-0:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.7 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.7 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
emv@bastion-0:~$ curl https://get.comtrya.dev | sudo sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  4304  100  4304    0     0  11803      0 --:--:-- --:--:-- --:--:-- 11824
x86_64
Downloading package https://github.com/comtrya/comtrya/releases/download/v0.5.1/comtrya-x86_64-unknown-linux-gnu as /tmp/comtrya-x86_64-unknown-linux-gnu
Download complete.

Running with sufficient permissions to attempt to move comtrya to /usr/local/bin
New version of comtrya installed to /usr/local/bin
comtrya: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by comtrya)

Feature request: Package provider for FreeBSD

A little background for any reader who might not be familiar with Unix-likes besides Linux:

Modern FreeBSD and DragonFly BSD use a package manager called pkg which has been available as an alternative from FreeBSD 8.4 onward and as the only supported pm since FreeBSD 10.0. It replaced what was known as the pkg*_ tools. The latter (or rather a re-implementation thereof) is still used on OpenBSD. On modern Solaris / illumos the "Image Packaging System" is used and the package manager for that is also called pkg.

Depending on how far Comtrya wants to take portability, it makes sense to consider this when choosing a provider name. Since Solaris and BSD use different manpage sections, a common differentiator is to use these when referring to either BSD's pkg(8) or Solaris' pkg(1). I'd probably call the provider "bsdpkg" or something; it's just helpful to be aware of the potential name clash upfront.

To allow for more rapid development, pkg(8) is not part of FreeBSD's base system. The system ships with a script, though, which transparently does the actual bootstrap and acts as a wrapper afterwards. FreeBSD's default shell is not bash but the C-shell variant called tcsh. This requires setting environment variables with env $SOMETHING=$VALUE $COMMAND-TO-RUN instead of $SOMETHING=$VALUE $COMMAND as you'd do with a bourne shell.

One thing to take into account regarding pkg(8) is that you are supposed to read the summary of actions to be taken before acknowledging it. The reason is that pkg deals with conflicts by proposing package removal of already installed packages. This is perfectly expected if e.g. installing Salt 300x on a system that still has Salt 2019 installed: As both install files to the same location, they are in conflict.

However in certain situations (due to interesting dependency issues) you can install a new package and end up having e.g. Libre Office or Firefox deleted. This definitely does not happen very often with the official FreeBSD repo, but somewhat more frequently for people rolling their own packages (which is a common thing to do). Since an automation tool cannot decide if pkg's proposal is the right thing for the system, this is a potential problem (I've had Salt screw up systems like this a couple of times over the years). Might make sense to choose safety by default here and allow for a special variable like "tolerate_remove" or something which defaults to "no".

To give the reader an impression of what that looks like, here's the output for trying to install the old version of Salt on a system that has a current version installed:

Checking integrity... done (1 conflicting)
  - py37-salt-2019-2019.2.8 conflicts with py37-salt-3002.5 on /usr/local/etc/salt/master.sample
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 4 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
        py37-salt: 3002.5

New packages to be INSTALLED:
        gmp: 6.2.1
        py37-pycrypto: 2.6.1_3
        py37-salt-2019: 2019.2.8

Number of packages to be removed: 1
Number of packages to be installed: 3

The operation will free 1 MiB.

Proceed with this action? [y/N]:

Here's some thoughts on an actual pkg provider:

Bootstrapping function:

• Check whether /usr/local/sbin/pkg exists
• Yes: Already bootstrapped, nothing to do
• No: Execute "env ASSUME_ALWAYS_YES=1 /usr/sbin/pkg bootstrap" to bootstrap without having to press "y"

Updating repository catalogue function (probably not even needed - pkg does this automatically if the catalogue is too old):

• Execute "pkg update"

Installing a package:

• If tolerating package removes on install: Execute "pkg install -y $PACKAGENAME"
• If not tolerating removes: Execute dry run "pkg install -n $PACKAGENAME"
• Parse output for "REMOVED", fail if encountered
• Execute "pkg install -y $PACKAGENAME"

Removing a package:

• Execute "pkg delete -y $PACKAGENAME"

Async DAG Runs

Currently the manifest DAG is run sequentially, this could be much faster if we run manifests at the same depth concurrently.

Switch to newer os_info crate

Just opening an issue here so this won't be forgotten. The bundled crate os_info needs to be updated for Comtrya to detect FreeBSD and DragonFly BSD (or a way needs to be found to use upstream os_info).

docs/examples: Tailscale installation on Ubuntu; requires `apt-key add`

Motivation: one of the first things I do when setting up a new node is put it on my Tailscale private network. comtrya should make this very easy, at the minimum by installing the necessary binaries, and (ideally) by propagating the necessary secrets or documenting the auth steps needed to turn up the network.

The Tailscale docs here https://tailscale.com/download/linux show the steps, which include downloading a signing key and adding a repository; the signing key in particular may require some updates to the Aptitude libraries to interface to apt-key add.