3 ms·

He has some good points, but... >All CI pipelines in the world which rely on docker setup/update or a system setup/update are broken. It is impossible to run a

He has some good points, but... >All CI pipelines in the world which rely on docker setup/update or a system setup/update are broken. It is impossible to run a system update or upgrade on an existing system. It’s impossible to create a new system and install docker on it. If the loss of package repos counts as a critical outage for you, you should be running your own package mirrors. Especially if you're not paying for commercial support and don't have anyone to escalate issues to.

user5994461 10y ago
The package repo is not lost. It is online and serving packages with corrupted signatures. That's a crypto error interpretable as an active MITM attack on the repo, which causes a apt-get and subcommands to terminate abruptly with a critical error. Last but not least, the repository is mirrored and cached, the mirrors simply reproduced the corrupted source repo :D It is not a mere case of offline repository, though I can understand the confusion ;)
- ryukafalz 10y ago
  I'm well aware of how traditional "dumb" mirrors work (e.g. ftpsync), and those would indeed just mirror the packages with their incorrect signatures. But for an internal network, surely you'd want something more like aptly[0] so you can roll back to a working version? [0] https://www.aptly.info/doc/overview/ https://www.aptly.info/doc/overview/
  - user5994461 10y ago
    aptly 1.0.0 => released on 27 march, that's exactly 1 month ago. First commit done in 2014. It's funny how people always mention workarounds that were non existent or non viable at the time of the issue. ;) I have worked on mirrors a few times in my career. I am sadly well aware than even the best mirroring solutions are rather poor. Not gonna argue that they have flaws. Not gonna argue that we wish for better.
    - ryukafalz 10y ago
      I suspect it was usable long before the 1.0 release - v0.1 from 2014 appears to have had repo snapshot support: https://github.com/smira/aptly/tree/3f82edf5d6c50ed6988297a436dfb5eb06754408 https://github.com/smira/aptly/tree/3f82edf5d6c50ed6988297a4... Nonetheless, it probably wasn't nearly as stable, and certainly wasn't as well-known then. So I'll concede that it may not have been viable at that point.
      - user5994461 10y ago
        Honestly, it's reasonable to live with an apt outage one day a year. Any workaround that adds critical components in the distribution chain is guaranteed to make it worse. The Docker crypto fuckup was quite peculiar. The distribution pipeline can't handle that. It also broke their other repos (including ubuntu) and propagated to the mirrors.

user5994461 10y ago

The package repo is not lost. It is online and serving packages with corrupted signatures. That's a crypto error interpretable as an active MITM attack on the repo, which causes a apt-get and subcommands to terminate abruptly with a critical error. Last but not least, the repository is mirrored and cached, the mirrors simply reproduced the corrupted source repo :D It is not a mere case of offline repository, though I can understand the confusion ;)

ryukafalz 10y ago
I'm well aware of how traditional "dumb" mirrors work (e.g. ftpsync), and those would indeed just mirror the packages with their incorrect signatures. But for an internal network, surely you'd want something more like aptly[0] so you can roll back to a working version? [0] https://www.aptly.info/doc/overview/ https://www.aptly.info/doc/overview/
- user5994461 10y ago
  aptly 1.0.0 => released on 27 march, that's exactly 1 month ago. First commit done in 2014. It's funny how people always mention workarounds that were non existent or non viable at the time of the issue. ;) I have worked on mirrors a few times in my career. I am sadly well aware than even the best mirroring solutions are rather poor. Not gonna argue that they have flaws. Not gonna argue that we wish for better.
  - ryukafalz 10y ago
    I suspect it was usable long before the 1.0 release - v0.1 from 2014 appears to have had repo snapshot support: https://github.com/smira/aptly/tree/3f82edf5d6c50ed6988297a436dfb5eb06754408 https://github.com/smira/aptly/tree/3f82edf5d6c50ed6988297a4... Nonetheless, it probably wasn't nearly as stable, and certainly wasn't as well-known then. So I'll concede that it may not have been viable at that point.
    - user5994461 10y ago
      Honestly, it's reasonable to live with an apt outage one day a year. Any workaround that adds critical components in the distribution chain is guaranteed to make it worse. The Docker crypto fuckup was quite peculiar. The distribution pipeline can't handle that. It also broke their other repos (including ubuntu) and propagated to the mirrors.