If you start to modify parts of the OpenEmbedded build (for the Unslung firmware and any part of OpenSlug or UcSlugC) you will eventually want to save your changes.

You can use your local monotone database to do this - you don't have to have write access to the nslu2-linux or OpenEmbedded databases to save changes locally. To write to the database, however, you must generate a key, and when you do so it is very important that you do not lose the private part of the key.

Choosing a monotone ID

The monotone key is, itself, your monotone identity, but when monotone uses the key it refers to it using a textual ID. Every ID in the database must be unique - therefore every key has to have a unique ID. What is more the ID is not local to the database - if your changes ever get pushed into remote databases the public part of your key and your chosen ID will go with the changes.

The convention used for openembedded development is to choose a key of the form userid@openembedded.org

You should chose an ID which can be related to the identifier you use on development related IRC channels (for example #nslu2-linux) and the nslu2-linux and OpenEmbedded (handhelds.org) mailing lists. If you don't do this and you later want to contribute changes to the nslu2-linux development you will probably be asked to chose a different ID. This is so that other developers can immediately identify who made a particular change!

Creating the monotone key

Once you have chosen your ID use the monotone command to generate a new key:

This places both the public and private part of the key into your database - if you are not in a monotone working directory you will need to give the --db option too.

Once you have created the key you must ensure that the private part never gets lost. Write the key to a reliable hard copy medium and store it somewhere where simultaneous damage to both it and your file systems is very unlikely. For example:

Then print out mykey.txt, copy it to a CD-R, write it into a flash memory device and store all three in secure bank vaults in separate banks.

This may seem a little anal-retentive, however, if you lose the private key you can never regenerate it (i.e. it is computationally impossible for you to recover it from the public key) and three things will happen:

1. You will be unable to commit any more changes with the corresponding public key (because you don't have the private key to generate the correct certificates).
2. You will be forced to generate a new ID - because even though you have lost the private key the public key is still in existence and cannot be removed once it is associated with a change in the database. Thus you cannot re-use the old ID.
3. You will be taunted, at least once and probably a second time.