7

I am trying to set up a YUM repository containing some RPM packages from our nightly Jenkins build.

The YUM repo resides on the Jenkins server in a repository folder [path to repo]/jenkins-nightly-build/[release name]-repo. After all the jobs are completed they are placed in the repo. Finally, the repository metadata is updated.

However, when I try to update another machine, the repository responds with [Errno 14] HTTP Error 403 - Forbidden.

Here is the .repo file that resides on the client machine:

[jenkins-nightly]
name=jenkins-nightly
baseurl=http://[hostname]/jenkins-nightly-build/[release name]-repo
gpgcheck=0
enabled=1

As you can see, the .repo file is pretty straight forward. I have tried yum clean all, and yum repolist does print the appropriate repo. All of the expected packages are printed and downloads are attempted when yum update is called. For some reason, the client does not have any access.

Is there some other configuration file I need to edit? Could Apache, which was installed for Jenkins, be interfering with the YUM repository? Please help!!! Let me know if any more information is needed.

scottysseus
  • 417
  • 1
  • 5
  • 10
  • 2
    Can you navigate to `$baseurl` in a web browser? If not, it's probably the permissions of the files and not a Yum configuration problem. Your script may need to set a less restrictive umask prior to building the RPM, or use setgid on the repo directory so that the web server has permission to the files. – Aaron Copley Jun 09 '15 at 19:15
  • what is interesting is that I can navigate to the `$baseurl` in a web browser, and from there I can even download files out of the `repodata` directory. Any time I try to download an RPM package, however, I am met with `403`. The Apache user has read/write/execute privileges in those directories. – scottysseus Jun 09 '15 at 19:18
  • Is there any kind of redirect occurring? Something the browser is smart enough to handle, but not Yum? What does a `curl` of `$baseurl` look like? – Aaron Copley Jun 09 '15 at 19:58
  • I figured the issue out. The issue was related to permissions, more specifically SELinux. Thanks for all of your help! – scottysseus Jun 09 '15 at 20:23
  • 1
    I don't understand how it worked in the web browser if it was SELinux..? – Aaron Copley Jun 09 '15 at 20:35

4 Answers4

1

I got it, and it was so simple!

In order to resolve this issue, I had to disable SELinux and reboot the server.

That's it.

scottysseus
  • 417
  • 1
  • 5
  • 10
  • 5
    FYI: You could have just added the correct context and relabel the directory. For example: `semanage fcontext -a -t httpd_sys_content_t "/path/to/repo(/.*)?" && restorecon -rV /path/to/repo` ([Obligatory](http://stopdisablingselinux.com/).) – Aaron Copley Jun 09 '15 at 20:34
  • Haha thanks for that. I will consider that route in the future, but for now my boss just asked me to disable SELinux – scottysseus Jun 10 '15 at 12:37
  • I hope you weren't downvoted because of my comment. Disabling SELinux isn't a *wrong* answer.. – Aaron Copley Jun 10 '15 at 15:51
1

It may happen that you don't have the password to reboot the server. It is not possible to disable without a reboot. But the mode can be set to permissive. (for this session only!)

setenforce 0 (changes from enforcing to permissive)

sestatus (to confirm the current mode)

sources:

How to disable selinux

original answer

Neilium
  • 11
  • 1
0

subscription-manager refresh have helped to solve a similar issue on a RHEL 7.9 server.

muthuh
  • 101
  • 1
0

The SELinux answers are probably the most likely to help, but in my case the network traffic had been blocked by our Networks department and the repo in question had to be added to our Satellite mirror.

Jimbali
  • 101
  • 1