FTP tests

The FTP tests have not been written yet.

HTTP tests

There are two styles of HTTP tests - actual HTTP downloads and HTTP HEAD tests.   Actual downloads happen when other tests need the files to be downloaded.   HEAD tests are where apt-panopticon probes things in detail.   For each mirror (including the DNS round robin domain), and for each IP of that mirror -

• Chose a small collection of package files to test, and the Release files for each release.
• Send a HTTP HEAD request for each of those files.
• Carefully inspect and log the response.
• Retry the request if needed, and log that.
• If the mirror replies with a redirect to the same mirror, then try that and keep checking.
• If the mirror replies with a redirect to a different server, then probe that mirror the same way.
• If a redirect loop is detected, log that and give up.

HTTPS tests

The HTTPS tests are very similar to the HTTP tests detailed above, though obviously they are tried with HTTPS requests instead of HTTP requests.   The validity of the HTTPS certificate for each server is tested as well.

RSYNC tests

The RSYNC tests have not been written yet.

DNS round robin

The "DNS round robin" column lists the IP addresses for each mirror that is part of the DNS round robin, or DNS-RR.   The IPs are linked to the log for that specific IP when used via the DNS round robin, and is followed by the number of ERRORs, WARNINGs, or TIMEOUTs if any.

Protocol tests

The Protocol test will give a WARNING if the protocol is changed during a redirect, HTTP -> HTTPS for example.   While apt HTTPS transport is now the default in Beowulf / Buster, not everyone with an older release will have that installed, so redirecting HTTP to HTTPS will break apt for those people.   An ERROR is given instead if that happens for mirrors in the DNS round robin.   Servers in the DNS round robin will not have the HTTPS certificate for the round robin domain, so redirecting to HTTPS for that is an ERROR.

Redirect tests

Mirrors that redirect /DEVUAN/ back out to deb.devuan.org is an ERROR.   /DEBIAN-SECURITY/ packages must be redirected to a Debian mirror, specifically a mirror hosting Debian security updates.   However, some Devuan mirrors might also be Debian mirrors, so this is just a WARNING.

URL sanity tests

The URL sanity test replaces "/" in URLS with "///", to see if the mirror can cope with that.   This might happen due to a minor mis-configuration by the apt user, but decent web servers should cope with that.   The result for a mirror that does not cope is a failed download for that user, so this is an ERROR.   We care about this coz apt has had multiple bugs in the past where they might let URLs like that slip through.

Integrity tests

Actually download files, then check things like PGP keys, SHA256 check sums, and file size.   For packages, pick the smallest one that has been recently updated.

Updated tests

Make sure the Release files are up to date by checking their internal "Date" field.   If they are up to date, download and check updated Packages.xz files, and actual packages.   For actual packages, pick the smallest one that has been recently updated.

Also shown is the mirrors scheduled time between updates, with "m" meaning minutes and "h" meaning hours.   If this is showing a WARNING, it's likely that the mirror hasn't updated yet, but is due to update after this test was run.

pkgmaster.devuan.org is the master that the other mirrors sync to, so it's untested.

Speed range

The speed test tries to guess at a minimum and maximum speed range for each mirror.   It does this by measuring the reported speeds from the curl commands that actually download files.   Since apt-panopticon is trying hard to download everything from all mirrors all at the same time, this guess will be low.   Also, the computer running the apt-panopticon might have a network connection that is busy with other things.   Not to mention that obviously if the computer this is running on is one of the mirrors, it might get a wildly exaggerated speed, not having to go through the rest of the Internet tends to help.   Finally, the tested mirror may have a bigger network connection than the computer running the test, so wont show it's true maximum.   So take this speed measurement with a grain of salt, it's more of an indication, the full graphs might be more useful.

Weekly statistics

This is the percentage of time, over the last week, that the mirror was up, and the percentage of time the mirror was up to date.   Note that if the mirror has a low uptime, then there wasn't much chance to check if it was up to date.

FTP tests

The FTP tests have not been written yet.

HTTP tests

There are two styles of HTTP tests - actual HTTP downloads and HTTP HEAD tests.   Actual downloads happen when other tests need the files to be downloaded.   HEAD tests are where apt-panopticon probes things in detail.   For each mirror (including the DNS round robin domain), and for each IP of that mirror -

• Chose a small collection of package files to test, and the Release files for each release.
• Send a HTTP HEAD request for each of those files.
• Carefully inspect and log the response.
• Retry the request if needed, and log that.
• If the mirror replies with a redirect to the same mirror, then try that and keep checking.
• If the mirror replies with a redirect to a different server, then probe that mirror the same way.
• If a redirect loop is detected, log that and give up.

HTTPS tests

The HTTPS tests are very similar to the HTTP tests detailed above, though obviously they are tried with HTTPS requests instead of HTTP requests.   The validity of the HTTPS certificate for each server is tested as well.

RSYNC tests

The RSYNC tests have not been written yet.

DNS round robin

The "DNS round robin" column lists the IP addresses for each mirror that is part of the DNS round robin, or DNS-RR.   The IPs are linked to the log for that specific IP when used via the DNS round robin, and is followed by the number of ERRORs, WARNINGs, or TIMEOUTs if any.

Protocol tests

The Protocol test will give a WARNING if the protocol is changed during a redirect, HTTP -> HTTPS for example.   While apt HTTPS transport is now the default in Beowulf / Buster, not everyone with an older release will have that installed, so redirecting HTTP to HTTPS will break apt for those people.   An ERROR is given instead if that happens for mirrors in the DNS round robin.   Servers in the DNS round robin will not have the HTTPS certificate for the round robin domain, so redirecting to HTTPS for that is an ERROR.

Redirect tests

Mirrors that redirect /DEVUAN/ back out to deb.devuan.org is an ERROR.   /DEBIAN-SECURITY/ packages must be redirected to a Debian mirror, specifically a mirror hosting Debian security updates.   However, some Devuan mirrors might also be Debian mirrors, so this is just a WARNING.

URL sanity tests

The URL sanity test replaces "/" in URLS with "///", to see if the mirror can cope with that.   This might happen due to a minor mis-configuration by the apt user, but decent web servers should cope with that.   The result for a mirror that does not cope is a failed download for that user, so this is an ERROR.   We care about this coz apt has had multiple bugs in the past where they might let URLs like that slip through.

Integrity tests

Actually download files, then check things like PGP keys, SHA256 check sums, and file size.   For packages, pick the smallest one that has been recently updated.

Updated tests

Make sure the Release files are up to date by checking their internal "Date" field.   If they are up to date, download and check updated Packages.xz files, and actual packages.   For actual packages, pick the smallest one that has been recently updated.

Also shown is the mirrors scheduled time between updates, with "m" meaning minutes and "h" meaning hours.   If this is showing a WARNING, it's likely that the mirror hasn't updated yet, but is due to update after this test was run.

pkgmaster.devuan.org is the master that the other mirrors sync to, so it's untested.

Speed range

The speed test tries to guess at a minimum and maximum speed range for each mirror.   It does this by measuring the reported speeds from the curl commands that actually download files.   Since apt-panopticon is trying hard to download everything from all mirrors all at the same time, this guess will be low.   Also, the computer running the apt-panopticon might have a network connection that is busy with other things.   Not to mention that obviously if the computer this is running on is one of the mirrors, it might get a wildly exaggerated speed, not having to go through the rest of the Internet tends to help.   Finally, the tested mirror may have a bigger network connection than the computer running the test, so wont show it's true maximum.   So take this speed measurement with a grain of salt, it's more of an indication, the full graphs might be more useful.

Weekly statistics

This is the percentage of time, over the last week, that the mirror was up, and the percentage of time the mirror was up to date.   Note that if the mirror has a low uptime, then there wasn't much chance to check if it was up to date.