TiUP Mirror Reference Guide

TiUP mirrors are TiUP’s component warehouse, which stores components and their metadata. TiUP mirrors take the following two forms:

  • Directory on the local disk: serves the local TiUP client, which is called a local mirror in this document.
  • HTTP mirror started based on the remote disk directory: serves the remote TiUP client, which is called a remote mirror in this document.

Create and update mirror

You can create a TiUP mirror using one of the following two methods:

  • Execute tiup mirror init to create a mirror from scratch.
  • Execute tiup mirror clone to clone from an existing mirror.

After the mirror is created, you can add components to or delete components from the mirror using the tiup mirror commands. TiUP updates a mirror by adding files and assigning a new version number to it, rather than deleting any files from the mirror.

Mirror structure

A typical mirror structure is as follows:

  1. + <mirror-dir> # Mirror's root directory
  2. |-- root.json # Mirror's root certificate
  3. |-- {2..N}.root.json # Mirror's root certificate
  4. |-- {1..N}.index.json # Component/user index
  5. |-- {1..N}.{component}.json # Component metadata
  6. |-- {component}-{version}-{os}-{arch}.tar.gz # Component binary package
  7. |-- snapshot.json # Mirror's latest snapshot
  8. |-- timestamp.json # Mirror's latest timestamp
  9. |--+ commits # Mirror's update log (deletable)
  10. |--+ commit-{ts1..tsN}
  11. |-- {N}.root.json
  12. |-- {N}.{component}.json
  13. |-- {N}.index.json
  14. |-- {component}-{version}-{os}-{arch}.tar.gz
  15. |-- snapshot.json
  16. |-- timestamp.json
  17. |--+ keys # Mirror's private key (can be moved to other locations)
  18. |-- {hash1..hashN}-root.json # Private key of the root certificate
  19. |-- {hash}-index.json # Private key of the indexes
  20. |-- {hash}-snapshot.json # Private key of the snapshots
  21. |-- {hash}-timestamp.json # Private key of the timestamps

Mirror Reference Guide - 图1

Note

  • The commits directory stores the logs generated in the process of mirror update and is used to roll back the mirror. You can delete the old log directories regularly when the disk space is insufficient.
  • The private key stored in the keys directory is sensitive. It is recommended to keep it separately.

Root directory

In a TiUP mirror, the root certificate is used to store the public key of other metadata files. Each time any metadata file (*.json) is obtained, TiUP client needs to find the corresponding public key in the installed root.json based on the metadata file type (root, index, snapshot, timestamp). Then TiUP client uses the public key to verify whether the signature is valid.

The root certificate’s format is as follows:

  1. {
  2. "signatures": [ # Each metadata file has some signatures which are signed by several private keys corresponding to the file.
  3. {
  4. "keyid": "{id-of-root-key-1}", # The ID of the first private key that participates in the signature. This ID is obtained by hashing the content of the public key that corresponds to the private key.
  5. "sig": "{signature-by-root-key-1}" # The signed part of this file by this private key.
  6. },
  7. ...
  8. {
  9. "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature.
  10. "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key.
  11. }
  12. ],
  13. "signed": { # The signed part.
  14. "_type": "root", # The type of this file. root.json's type is root.
  15. "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file.
  16. "roles": { # Records the keys used to sign each metadata file.
  17. "{role:index,root,snapshot,timestamp}": { # Each involved metadata file includes index, root, snapshot, and timestamp.
  18. "keys": { # Only the key's signature recorded in `keys` is valid.
  19. "{id-of-the-key-1}": { # The ID of the first key used to sign {role}.
  20. "keytype": "rsa", # The key's type. Currently, the key type is fixed as rsa.
  21. "keyval": { # The key's payload.
  22. "public": "{public-key-content}" # The public key's content.
  23. },
  24. "scheme": "rsassa-pss-sha256" # Currently, the scheme is fixed as rsassa-pss-sha256.
  25. },
  26. "{id-of-the-key-N}": { # The ID of the Nth key used to sign {role}.
  27. "keytype": "rsa",
  28. "keyval": {
  29. "public": "{public-key-content}"
  30. },
  31. "scheme": "rsassa-pss-sha256"
  32. }
  33. },
  34. "threshold": {N}, # Indicates that the metadata file needs at least N key signatures.
  35. "url": "/{role}.json" # The address from which the file can be obtained. For index files, prefix it with the version number (for example, /{N}.index.json).
  36. }
  37. },
  38. "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0.
  39. "version": {N} # The version number of this file. You need to create a new {N+1}.root.json every time you update the file, and set its version to N + 1.
  40. }
  41. }

Index

The index file records all the components in the mirror and the owner information of the components.

The index file’s format is as follows:

  1. {
  2. "signatures": [ # The file's signature.
  3. {
  4. "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature.
  5. "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key.
  6. },
  7. ...
  8. {
  9. "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature.
  10. "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key.
  11. }
  12. ],
  13. "signed": {
  14. "_type": "index", # The file type.
  15. "components": { # The component list.
  16. "{component1}": { # The name of the first component.
  17. "hidden": {bool}, # Whether it is a hidden component.
  18. "owner": "{owner-id}", # The component owner's ID.
  19. "standalone": {bool}, # Whether it is a standalone component.
  20. "url": "/{component}.json", # The address from which the component can be obtained. You need to prefix it with the version number (for example, /{N}.{component}.json).
  21. "yanked": {bool} # Indicates whether the component is marked as deleted.
  22. },
  23. ...
  24. "{componentN}": { # The name of the Nth component.
  25. ...
  26. },
  27. },
  28. "default_components": ["{component1}".."{componentN}"], # The default component that a mirror must contain. Currently, this field defaults to empty (disabled).
  29. "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file.
  30. "owners": {
  31. "{owner1}": { # The ID of the first owner.
  32. "keys": { # Only the key's signature recorded in `keys` is valid.
  33. "{id-of-the-key-1}": { # The first key of the owner.
  34. "keytype": "rsa", # The key's type. Currently, the key type is fixed as rsa.
  35. "keyval": { # The key's payload.
  36. "public": "{public-key-content}" # The public key's content.
  37. },
  38. "scheme": "rsassa-pss-sha256" # Currently, the scheme is fixed as rsassa-pss-sha256.
  39. },
  40. ...
  41. "{id-of-the-key-N}": { # The Nth key of the owner.
  42. ...
  43. }
  44. },
  45. "name": "{owner-name}", # The name of the owner.
  46. "threshold": {N} # Indicates that the components owned by the owner must have at least N valid signatures.
  47. },
  48. ...
  49. "{ownerN}": { # The ID of the Nth owner.
  50. ...
  51. }
  52. }
  53. "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0.
  54. "version": {N} # The version number of this file. You need to create a new {N+1}.index.json every time you update the file, and set its version to N + 1.
  55. }
  56. }

Component

The component’s metadata file records information of the component-specific platform and the version.

The component metadata file’s format is as follows:

  1. {
  2. "signatures": [ # The file's signature.
  3. {
  4. "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature.
  5. "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key.
  6. },
  7. ...
  8. {
  9. "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature.
  10. "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key.
  11. }
  12. ],
  13. "signed": {
  14. "_type": "component", # The file type.
  15. "description": "{description-of-the-component}", # The description of the component.
  16. "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file.
  17. "id": "{component-id}", # The globally unique ID of the component.
  18. "nightly": "{nightly-cursor}", # The nightly cursor, and the value is the latest nightly version number (for example, v5.0.0-nightly-20201209).
  19. "platforms": { # The component's supported platforms (such as darwin/amd64, linux/arm64).
  20. "{platform-pair-1}": {
  21. "{version-1}": { # The semantic version number (for example, v1.0.0).
  22. "dependencies": null, # Specifies the dependency relationship between components. The field is not used yet and is fixed as null.
  23. "entry": "{entry}", # The relative path of the entry binary file in the tar package.
  24. "hashs": { # The checksum of the tar package. sha256 and sha512 are used.
  25. "sha256": "{sum-of-sha256}",
  26. "sha512": "{sum-of-sha512}",
  27. },
  28. "length": {length-of-tar}, # The length of the tar package.
  29. "released": "{release-time}", # The release date of the version.
  30. "url": "{url-of-tar}", # The download address of the tar package.
  31. "yanked": {bool} # Indicates whether this version is disabled.
  32. }
  33. },
  34. ...
  35. "{platform-pair-N}": {
  36. ...
  37. }
  38. },
  39. "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0.
  40. "version": {N} # The version number of this file. You need to create a new {N+1}.{component}.json every time you update the file, and set its version to N + 1.
  41. }

Snapshot

The snapshot file records the version number of each metadata file:

The snapshot file’s structure is as follows:

  1. {
  2. "signatures": [ # The file's signature.
  3. {
  4. "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature.
  5. "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key.
  6. },
  7. ...
  8. {
  9. "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature.
  10. "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key.
  11. }
  12. ],
  13. "signed": {
  14. "_type": "snapshot", # The file type.
  15. "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file.
  16. "meta": { # Other metadata files' information.
  17. "/root.json": {
  18. "length": {length-of-json-file}, # The length of root.json
  19. "version": {version-of-json-file} # The version of root.json
  20. },
  21. "/index.json": {
  22. "length": {length-of-json-file},
  23. "version": {version-of-json-file}
  24. },
  25. "/{component-1}.json": {
  26. "length": {length-of-json-file},
  27. "version": {version-of-json-file}
  28. },
  29. ...
  30. "/{component-N}.json": {
  31. ...
  32. }
  33. },
  34. "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0.
  35. "version": 0 # The version number of this file, which is fixed as 0.
  36. }

Timestamp

The timestamp file records the checksum of the current snapshot.

The timestamp file’s format is as follows:

  1. {
  2. "signatures": [ # The file's signature.
  3. {
  4. "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature.
  5. "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key.
  6. },
  7. ...
  8. {
  9. "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature.
  10. "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key.
  11. }
  12. ],
  13. "signed": {
  14. "_type": "timestamp", # The file type.
  15. "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file.
  16. "meta": { # The information of snapshot.json.
  17. "/snapshot.json": {
  18. "hashes": {
  19. "sha256": "{sum-of-sha256}" # snapshot.json's sha256.
  20. },
  21. "length": {length-of-json-file} # The length of snapshot.json.
  22. }
  23. },
  24. "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0.
  25. "version": {N} # The version number of this file. You need to overwrite timestamp.json every time you update the file, and set its version to N + 1.

Client workflow

The client uses the following logic to ensure that the files downloaded from the mirror are safe:

  • A root.json file is included with the binary when the client is installed.
  • The running client performs the following tasks based on the existing root.json:
    1. Obtain the version from root.json and mark it as N.
    2. Request {N+1}.root.json from the mirror. If the request is successful, use the public key recorded in root.json to verify whether the file is valid.
    3. Request timestamp.json from the mirror and use the public key recorded in root.json to verify whether the file is valid.
    4. Check whether the checksum of snapshot.json recorded in timestamp.json matches the checksum of the local snapshot.json. If the two do not match, request the latest snapshot.json from the mirror and use the public key recorded in root.json to verify whether the file is valid.
    5. Obtain the version number N of the index.json file from snapshot.json and request {N}.index.json from the mirror. Then use the public key recorded in root.json to verify whether the file is valid.
    6. For components such as tidb.json and tikv.json, the client obtains the version numbers N of the components from snapshot.json and requests {N}.{component}.json from the mirror. Then the client uses the public key recorded in index.json to verify whether the file is valid.
    7. For component’s tar files, the client obtains the URLs and checksums of the files from {component}.json and request the URLs for the tar packages. Then the client verifies whether the checksum is correct.