Closed brianloss closed 3 years ago
Ha, I missed that @arvindshmicrosoft already had a similar PR for this out there, and I saw the comments. Given that, I can maybe limit updates on the proxy to include only ca-certificates so at least downloads can succeed without skipping SSL certificate verification.
Modified this PR to update only ca-certificates package. This will allow muchos to work when configured with older VM images where the CA certs were out of date and wouldn't work with the newer apache download servers.
Hi @brianloss as you mentioned re: older PR - I wonder if we should just start using the 7.9 image instead?
Hi @brianloss as you mentioned re: older PR - I wonder if we should just start using the 7.9 image instead?
@arvindshmicrosoft That's probably a good idea as well. I feel like updating the CA certs is a good protection that should help with deploying on older images and shouldn't hurt (or could argue is a good idea) for newer images as well.
This seems like a more narrow version of the currently stalled PR #408
The question there was essentially: Why not just expect one to use an up-to-date base image? If the base image is out of date, the user can add this themselves, or update it with cloud-init or the equivalent, rather than try to bloat our ansible setup, which should probably just focus on setting up our stuff on top of the base image. See discussion on #408 for more.
It is a more narrow version of #408. I tried to do what is effectively a vanilla install on azure with the example defaults, and it failed in a somewhat confusing manner because packages couldn't be downloaded from the Apache mirrors. The SSL cert validation failed because the CAs were out of date. I wouldn't call it bloat to ensure that the underlying image is updated to the minimums necessary to run the ansible playbooks (in this case executing get_url against apache servers). If we want to be more explicit and say CentOS 7.5 is too old and no longer supported, that's fine too. @arvindshmicrosoft suggested changing the image in muchos.props.example to 7.9. Let me know if you prefer that instead, and I'll either make that change, or address your other comments.
I wouldn't call it bloat to ensure that the underlying image is updated to the minimums necessary to run the ansible playbooks (in this case executing get_url against apache servers).
I just think using an updated image makes more sense.
If we want to be more explicit and say CentOS 7.5 is too old and no longer supported, that's fine too.
So, just to be clear, no versions are "supported". This repo is unreleased software created for internal testing by the Fluo (and Accumulo) developers. The intent is that the contents of the repo are what the developers are using, to make their lives easier. We don't do releases, and we don't do any kind of support. If devs are still doing testing of Fluo or Accumulo on 7.5, it's fine if we make that work. However, I don't see any reason they should still be testing on those versions, since there are more up-to-date versions of CentOS 7 to test with.
@arvindshmicrosoft suggested changing the image in muchos.props.example to 7.9. Let me know if you prefer that instead, and I'll either make that change, or address your other comments.
Is 7.9 the latest 7? Strong +1 to just updating the example to use the latest CentOS 7 AMI, if that works.
If we want to be more explicit and say CentOS 7.5 is too old and no longer supported, that's fine too.
So, just to be clear, no versions are "supported". This repo is unreleased software created for internal testing by the Fluo (and Accumulo) developers. The intent is that the contents of the repo are what the developers are using, to make their lives easier. We don't do releases, and we don't do any kind of support. If devs are still doing testing of Fluo or Accumulo on 7.5, it's fine if we make that work. However, I don't see any reason they should still be testing on those versions, since there are more up-to-date versions of CentOS 7 to test with.
Sure, support was probably not the best choice of words. We have caveats for other things that are known not to work. Perhaps that doesn't make sense for the image version, especially since I don't really feel like figuring out which CentOS image is the first one with a new enough version of ca-certificates to work. :)
@arvindshmicrosoft suggested changing the image in muchos.props.example to 7.9. Let me know if you prefer that instead, and I'll either make that change, or address your other comments.
Is 7.9 the latest 7? Strong +1 to just updating the example to use the latest CentOS 7 AMI, if that works.
@ctubbsii I updated the Azure default image. 7.9 is the latest 7.x on Azure. I don't have AWS resources to test, so I didn't make changes there. However, this page indicates official CentOS images are now published outside of the marketplace. It looks like ami-00e87074e52e6c9f9 is the latest 7.9 image for us-east-1. I'm happy to make that change if you're comfortable with it going in without testing.
I updated the Azure default image. 7.9 is the latest 7.x on Azure. I don't have AWS resources to test, so I didn't make changes there. However, this page indicates official CentOS images are now published outside of the marketplace. It looks like ami-00e87074e52e6c9f9 is the latest 7.9 image for us-east-1. I'm happy to make that change if you're comfortable with it going in without testing.
That's fine. We can update the AWS example AMI separately, once somebody has a chance to test that image. I have no reason to suspect it won't work, but I'm fine with waiting until somebody who needs it has time to test it. I was able to confirm the AMI for us-east-1 from the page at https://www.centos.org/download/aws-images/ as well as https://wiki.centos.org/Cloud/AWS
The previous default of CentOS 7.5 contained a version of ca-certificates that was too old to allow SSL certificate validation when downloading packages from Apache download servers. Update to the latest 7.x version of CentOS (not using CentOS 8 since its support is EOL on 2021-12-31).