Configure Aptly¶

Normally you don't need to modify the Aptly default configuration to use it. Because the default values are OK for most cases. Especially, if you created an additional aptly user and its home directory resides on the desired big (caching) partition because mirroring of repositories may require 200-400 GB.

If your default root folder does not have enough space to host the mirrored packages, you need to change the conf to put them elsewhere.

The official doc can be found here

Default conf¶

The default conf file is located at ~/.aptly.conf. It's in json format.

aptly looks for configuration file first in ~/.aptly.conf then in /etc/aptly.conf and, if no config file found, new one is created in home directory. If -config= flag is specified, aptly would use config file at specified location. Also aptly needs root directory for database, package and published repository storage. If not specified, directory defaults to ~/.aptly, it will be created if missing.

Below is an example of the generated .aptly.conf file.

aptly@debian:~$ cat .aptly.conf
{
  "rootDir": "/home/aptly/.aptly",
  "downloadConcurrency": 4,
  "downloadSpeedLimit": 0,
  "downloadRetries": 0,
  "downloader": "default",
  "databaseOpenAttempts": -1,
  "architectures": [],
  "dependencyFollowSuggests": false,
  "dependencyFollowRecommends": false,
  "dependencyFollowAllVariants": false,
  "dependencyFollowSource": false,
  "dependencyVerboseResolve": false,
  "gpgDisableSign": false,
  "gpgDisableVerify": false,
  "gpgProvider": "gpg",
  "downloadSourcePackages": false,
  "skipLegacyPool": true,
  "ppaDistributorID": "ubuntu",
  "ppaCodename": "",
  "skipContentsPublishing": false,
  "skipBz2Publishing": false,
  "FileSystemPublishEndpoints": {},
  "S3PublishEndpoints": {},
  "SwiftPublishEndpoints": {},
  "AzurePublishEndpoints": {},
  "AsyncAPI": false,
  "enableMetricsEndpoint": false

Change the root dir¶

As we mentioned above, by default, eveything is stored in the root dir ~/.aptly. - The database will be sotred in rootDir/db - The downloaded packages will be stored in rootDir/pool - The published repositories will be sotred in rootDir/public

So if your ~/ folder does not have enough space, you need to modify the default root dir to a bigger hard drive.

Download concurrency¶

We can also configure the number of parallel download threads to use when downloading packages Below conf means that the thread number will be 4

"downloadConcurrency": 4,

Speed limit¶

To avoid the aptly consume all network bandwidth, we can set a speed limits. Below are some example conf

# The limit on download bandwidth is set to 100 `kbytes per second`
"downloadSpeedLimit": 100,

# 0 means unlimited
"downloadSpeedLimit": 0,

Architectures¶

Linux release packages for different CPU architecutres (e.g. amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x). We often need to only mirror packages for one CPU architecture. This can save many disk spaces, if we don't download the package for all architectures.

Below are some examples

# we only download packages for amd64
"architectures": ["amd64"],

# if empty, by default it will download all available architectures
"architectures": [],

FileSystemPublishEndpoints¶

aptly defaults to publish to a single publish directory under ~/.aptly/public. For a more advanced publishing strategy, you can define one or more filesystem endpoints in the FileSystemPublishEndpoints list of the aptly configuration file.

Below are some examples

...
"FileSystemPublishEndpoints": {
  "test1": {
    "rootDir": "/opt/srv1/aptly_public",
    "linkMethod": "symlink"
  },
  "test2": {
    "rootDir": "/opt/srv2/aptly_public",
    "linkMethod": "copy",
    "verifyMethod": "md5"
  },
  "test3": {
    "rootDir": "/opt/srv3/aptly_public",
    "linkMethod": "hardlink"
  }
},
...

rootDir: defines the publishing directory
linkMethod: defines how aptly links the files from the internal pool to the published directory. Three possible values: hardlink, symlink or copy. If not specified, empty or wrong, the default value is hardlink.
verifyMethod: This is used only when setting the linkMethod to copy. Possible values are md5 and size. It specifies how aptly compares existing links from the internal pool to the published directory. The size method compares only the file sizes, whereas the md5 method calculates the md5 checksum of the found file and compares it to the desired one. If not specified, empty or wrong, this defaults to md5.

hardlink vs symlink vs copy¶

Underneath the file system, files are represented by inodes. (Or is it multiple inodes? Not sure.)

A file in the file system is basically a link to an inode.

A hard link, then, just creates another file with a link to the same underlying inode.

When you delete a file, it removes one link to the underlying inode. The inode is only deleted (or deletable/over-writable) when all links to the inode have been deleted.

A symbolic link is a link to another name in the file system.

Once a hard link has been made the link is to the inode. Deleting, renaming, or moving the original file will not affect the hard link as it links to the underlying inode. Any changes to the data on the inode are reflected in all files that refer to that inode.

Note: Hard links are only valid within the same File System. Symbolic links can span file systems as they are simply the name of other files.

Copy will duplicate the inodes and then create a new link. This will consume hard drive space unlike the symlink and hardlink

Use endpoint when publishing¶

In order to publish to a predefined endpoint, specify the endpoint as filesystem:endpoint-name with endpoint-name as the name given in the aptly configuration file. For example:

# default general syntax
aptly publish snapshot -distribution=<distribution-name> <snapshot-name>

# To use add file system option before snapshot-name
aptly publish snapshot -distribution=<distribution-name> filesystem:<endpoint-name>:<snapshot-name>

# for example we want to publish snapshot bullseye-stable-20230206 to endpoint test1
aptly publish snapshot -distribution=bullseye filesystem:test1:bullseye-stable-20230206

Manage GPG keys¶

All the packages which are published by Aptly are signed with a GPG key. The client can then use the public key to verify the authenticity and integrity of the package. So when you publish the packages on the server side, aptly will try to use the GPG private key to sign them. In general, this private key is protected by a password.

# change the password of the private key aptly
# here aptly is the id of the private key
gpg --passwd --change-passphrase aptly