I believe we've figured this out. It's a combination of two issues: 1) The S3 bucket(s) hosting the elastic.co repos apparently do not have the s3:ListBucket permission, which causes the AF "test" button to fail (with a 404 error) as well as attempts to browse to elastic.co repo paths in the browser.
2) Even though the AF "test" fails, the remote repo definition can still be saved. At that point, however, testing it showed a 403 error which I thought also came from S3. But, the 403 in fact came from AF as a result of the AF user not having deploy permissions on that remote repo. Once this permission was added, the remote repo pointing to one of elastic.co's repos began working! Just recording the final outcome here for posterity... -- View this message in context: http://forums.jfrog.org/Problems-connecting-to-remote-YUM-package-repositories-tp7581046p7581067.html Sent from the Artifactory - Users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Artifactory-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/artifactory-users
