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.

5
  • 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. Jun 9, 2015 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. Jun 9, 2015 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? Jun 9, 2015 at 19:58
  • I figured the issue out. The issue was related to permissions, more specifically SELinux. Thanks for all of your help! Jun 9, 2015 at 20:23
  • 1
    I don't understand how it worked in the web browser if it was SELinux..? Jun 9, 2015 at 20:35

4 Answers 4

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.

3
  • 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.) Jun 9, 2015 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 Jun 10, 2015 at 12:37
  • I hope you weren't downvoted because of my comment. Disabling SELinux isn't a wrong answer.. Jun 10, 2015 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

0

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

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .