When trying to install modules or run composer update, this error appears curl error 28 while downloading

Some slack threads with a similar issue (some have replies that might help).

#support: https://drupal.slack.com/archives/C1BB308HH/p1687275285720649
#composer: https://drupal.slack.com/archives/C392CHBEW/p1687170644290709
#drupal-infrastructure: https://drupal.slack.com/archives/C51GNJG91/p1687163128077509

Isn't this an issue for the packages.drupal.org project? That is the main module used in https://packages.drupal.org.

Agree. Moving the issue to the right project, but also marking it as Postponed as we'd need more info to really know if it's a local-only problem vs a module or endpoint issue.

The packages.drupal.org project is more about the content of the server, connections themselves would be infrastructure.

Is this happening consistently? Likely, it was a temporary issue with our CDN, your ISP, or the connections between them.

If this is happening often - what IP does packages.drupal.org resolve to for you?

AWS is about to increase the cost of Lightsail instances that support both IPv4 and IPv6, essentially the IPv4. They recommend creating a new instance that is only IPv6. I have tried both using a snapshot of my functioning IPv4/IPv6 instance and creating a new instance with ubuntu and installing a LAMP stack manually. My curl is 7.81.0, php 8.2.16 and composer 2.7.2

"Composer could not detect the root package (drupal/recommended-project) version, defaulting to '1.0.0'. See https://getcomposer.org/root-version"

curl error 28 while downloading https://packages.drupal.org/8/packages.json
: Connection timeout after 10004 ms

As I have no difficulty using composer update on the IPv4/IPv6 site I must assume that there is a problem with the missing IPv4 address.

Drupal.org currently only supports IPv4. Where specifically do you see “a problem with the missing IPv4 address”? Or was that a typo and IPv6 is actually missing?

The problems seems to be that my AWS instance is IPv6 exclusively. If Drupal.org supports only IPv4 then I suppose there is no solution. My live site cannot receive security alerts and composer cannot download modules. My work-around is to maintain this site with rsync from my development box.

Running Composer in production is not recommended anyway, although is a lot safer with Composer 2. Composer 2 internally has much fewer places that could leave your codebase in an indeterminate state if something goes wrong.

With this clarification, this does look like a duplicate of #463424: Drupal.org reachable by IPv6? →

Running Composer in production is not recommended anyway [...]

I have previously looked for recommendations either way on both https://github.com/composer/composer and https://getcomposer.org/ but didn't find any ... do you have a link for that recommendation @drumm?

Not offhand, I would apply the same to any package management, like npm, pypi, etc. Production deployments should be as atomic as possible, deploying artifacts instead of building them. If something has changed, or some part of the internet is flaky, production is not the place to find out. Composer 1 was particularly error-prone, since the codebase changes started before other steps were complete. I believe Composer 2 is as good as it can be, with more distinct phases and copying everything at once, after build is done; so you won't have a codebase in an indeterminate state unless there is a badly-timed hardware failure. A maintainer could still introduce randomness, GitHub-hosted tagged releases can change to different code or be deleted.

Thanks for a fast reply, and I do agree: Composer 2 is a big improvement from version 1, which was slow and slightly buggy. Composer 2 has been rock solid for me so far, and I can only think of one instance where there was a small hiccup (a time out I think) and that was locally, doing experimentation in DDEV, so no problem. But for setting code in production, composer 2 has performed flawlessly. But it's always a good idea to consider alternative, possibly safer methods.

This seems to be a Composer timeout issue. When I ran:
composer config --global process-timeout 2000 and re-ran my ddev composer command to install Bootstrap 5, it worked. Hopefully this helps.