Osquery: Error 404 - osquery RPM package repository not found

[Iwant2learn]

Hello,

Recently noticed that the baseurl used in osquery RPM repo is no longer accessible.

I am getting following error when trying to install osquery with the configured yum repository
( https://pkg.osquery.io/rpm/osquery-s3-rpm.repo )

https://s3.amazonaws.com/osquery-packages/rpm/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found

I have noticed this before as well. Does this happen when osquery is releasing a new version ?
is there a work-around ?

Thanks,
Prathamesh

[krish7919]

https://github.com/osquery/osquery/issues/6233#issuecomment-588566466

[Iwant2learn]

#6233 (comment)

Hi, I am noticing this on all version of RPM Linux ( centos / RHEL 6.x - 8.x )

[mlasky1970]

Same with Amazon-Linux2.

[mire3212]

Also experiencing this issue and it's breaking our automation.

[Iwant2learn]

Also experiencing this issue and it's breaking our automation.

same here :(

[Iwant2learn]

I guess someone is already on it.... because the error message for me has changed ... now I am getting this - "Error: requested datatype primary not available"

[rwinfosec]

We are also experiencing this issue as of today: "Error: requested datatype primary not available"

[charlesdunbar]

Switching the URL to https://osquery-packages.s3.amazonaws.com/rpm/$basearch/ seems to fix the issue.

[theopolis]

Ah sorry about this. I can try to fix the region the bucket is hosted in but it will require more downtime, as there are delays in bucket recreation imposed by AWS.

[theopolis]

I've started the process, this should complete in 2 hours.

[mallikharjunakambampati]

We also face the same issue with repo, please try to use AWS CLI to delete the bucket and recreate, it won't take much time I think.

[mark-wagner]

Similar for the deb packages:

STDERR: E: Failed to fetch https://osquery-packages.s3.amazonaws.com/deb/dists/deb/InRelease  403  Forbidden [IP: 52.217.70.188 443]

Will it be fixed as well?

[theopolis]

Ok the bucket has been moved back to us-east-1, please let me know if there are further issues.

[nathanvicen]

Linux install still failing with E: Failed to fetch https://pkg.osquery.io/deb/dists/deb/InRelease 301 Moved Permanently

[theopolis]

Linux install still failing with E: Failed to fetch https://pkg.osquery.io/deb/dists/deb/InRelease 301 Moved Permanently

This seems like a CloudFront issue that will need more investigation. We've never served an InRelease, only a Release. If I navigate to this url in a browser I get the correct 404 response.

[ryanbrainard]

Unbuntu 14.04 is failing with:

W: Failed to fetch https://pkg.osquery.io/deb/dists/deb/main/binary-amd64/Packages gnutls_handshake() failed: A TLS packet with unexpected length was received.

E: Some index files failed to download. They have been ignored, or old ones used instead.

According to this, it sounds like a problem git and/or openssl accessing repos behind proxies. With the mention of CloudFront here, I'm thinking that might be the case since that is acting as a proxy of sorts.

[ryanbrainard]

Similar to https://github.com/osquery/osquery/issues/6653#issuecomment-694366238, using this repo URL for Deb packages worked to fix my issue above (https://github.com/osquery/osquery/issues/6653#issuecomment-694619061):

https://osquery-packages.s3.amazonaws.com/deb

[res0nat0r]

A standard apt-get install worked fine for me as of a couple of hours ago, I believe whatever CloudFront / S3 bucket issue should now be fixed.

[Iwant2learn]

Everything is back to normal now. Thank you very much for resolving this at the earliest.

[ryanbrainard]

I tried switching back the repo in our project, but this is still not working on Ubuntu 14.04, which I'm thinking might be a CloudFront incompatibility. Is using osquery-packages.s3.amazonaws.com acceptable as a long term solution or perhaps some other setting needs to be changed in CloudFront? From https://github.com/nodesource/distributions/issues/388, it sounds like it might be related to the use of SNI in Cloudfront.

[theopolis]

Hi @ryanbrainard, this might be because the old CloudFront distribution supported TLS1.1 and the new distribution was set to TLS1.2 only. I've updated this setting to reflect the previous support. I think this will fix the issue.

[theopolis]

Let me know if there's still an issue. I am not sure if we'll be able to find a solution but I'd at least like to know if there's still a known problem.

[ryanbrainard]

@theopolis I can confirm that the TLS change fixed the issue. Thank you!