repo.aptly.info is missing IPv6 and/or AAAA records

[mattock]

Aptly cannot be installed with the usual installation method when one does not have IPv4 egress to the Internet. This is because the repository servers (repo.aptly.info) either don't have AAAA records in DNS, don't have firewall rules to allow IPv6 traffic or don't have IPv6 addresses at all:

$ dig +short AAAA repo.aptly.info
$ dig +short A repo.aptly.info
3.5.134.217
3.5.134.60
52.219.75.86
3.5.135.118
52.219.72.130
52.219.47.162
52.219.169.192

Would it be possible to resolve this? The repository seems to be in AWS S3 so maybe there's a switch you could switch to enable IPv6?

[mcpherrinm]

AWS' "s3-website" feature doesn't support IPv6.

You could try to access the bucket directly via the S3 "dual-stack" endpoints which support IPv6

deb https://s3.dualstack.eu-central-1.amazonaws.com/repo.aptly.info/ squeeze main

I don't know how the aptly maintainers would feel about that, as it would mean if they pointed repo.aptly.info elsewhere, you'd keep using the same old s3 bucket.

[mcpherrinm]

For the aptly maintainers, one option here is to configure Cloudfront with an S3 backend, which I believe would also reduce your bandwidth costs. Happy to chat privately/offline about AWS configuration if you're interested.

[mattock]

For the aptly maintainers, one option here is to configure Cloudfront with an S3 backend, which I believe would also reduce your bandwidth costs. Happy to chat privately/offline about AWS configuration if you're interested.

This would definitely solve the issue. However, some extra magic would be required to clear Cloudfront caches whenever packages are updated in S3.

[mattock]

AWS' "s3-website" feature doesn't support IPv6.

You could try to access the bucket directly via the S3 "dual-stack" endpoints which support IPv6

deb https://s3.dualstack.eu-central-1.amazonaws.com/repo.aptly.info/ squeeze main

I don't know how the aptly maintainers would feel about that, as it would mean if they pointed repo.aptly.info elsewhere, you'd keep using the same old s3 bucket.

I'll try that, thanks!

[neolynx]

would also fix #402 as SSL is required