How to add repositories to Red Hat Linux with and without a proxy

Objective

Our objective is to set up access to internal and remote yum repositories while some of them are behind proxy servers.

Operating System and Software Versions

  • Operating system: Red Hat Enterprise Linux 7.5

Requirements

Privileged access to the system

Difficulty

EASY

Conventions

  • # – requires given linux commands to be executed with root privileges either directly as a root user or by use of sudo command
  • $ – given linux commands to be executed as a regular non-privileged user

Introduction

In a corporate environment it is common to limit Internet access – both for security and accountability. This is often accomplished by using proxy servers that enable access to the Internet after some sort of authentication, while inspect and log all traffic passing trough them. This way the company can, for example find the employee who downloaded the virus that wreak havoc within the corporate system (or at least the employee who’s credentials where stolen to do so), or filter the traffic, preventing access to well-known harmful sites to protect employee equipment.

There may be other type of Internet access needed, however: as a sysadmin, you need software updates for the servers to keep them up to date. This traffic can pass trough the proxy as well, if you setup yum to use proxy. But what about the internal repositories that aren’t reachable with this setup, as they are within the LAN? Where to place this setting if the machine in question is a desktop, utilized for browsing as well? Let’s find out how to set up some possible use cases with Red Hat Linux.



Tutorial setup

In this tutorial we assume that the proxy in our environment is proxy.foobar.com, serving on port 8000, and requires a simple username/password authentication to give access to the rest of the world. Valid credentials are foouser as username and secretpass as password. Note that your proxy may be entirely different, may not need password, or even username, it depends on it’s configuration.

Ad hoc connection trough proxy

If you need to connect trough the proxy once, for example download a package from command line, or test connectivity before finalizing the configuration, you can export the proxy related variables to your current command line session:

$ export http_proxy=http://foouser:secretpass@proxy.foobar.com:8000

You can set the https_proxy variable the same way.

Until you terminate the session, or unset the exported variable, the http (or https) traffic will try to connect to the proxy – including the traffic generated by yum. Keep in mind that this causes a valid proxy username and password to be present in the user’s history! This may be sensitive information not intended to be readable by others who can access the history file.

All traffic is using proxy

If the system as a whole need to use the proxy in order to reach out, you could set the proxy in /etc/profile, or drop the variables in a separate file into /etc/profile.d directory, so these settings only need to be modified in one place. There may be use cases for this, but also keep in mind that in this case any and all traffic is tried trough the proxy – so a browser will try to reach internal pages via proxy as well.

Note that we set the same environmental variable as we did with the one time proxy connection, only setting it on startup, therefore all user sessions “inherit” these variables.

If you need to set the proxy system wide, add the following to the /etc/profile or a separate file under the /etc/profile.d directory, using your favorite text editor:

export http_proxy=http://foouser:secretpass@proxy.foobar.com:8000
export https_proxy=http://foouser:secretpass@proxy.foobar.com:8000

You can set these a per user level as well (for example in .bash_profile), in which case they only apply for that particular user. The same way any user can override these system wide settings by adding new value to these variables.



In the reminder of this tutorial we will focus on yum and it’s configured repositories, so we assume that we don’t have or need system wide proxy settings. This may make sense even if users browsing on the machine must use proxy to reach the Internet.

For example, users of a desktop will need to use their own credentials, and more than one user may have access to the given desktop. but when the admin performs a deployment on all client desktops (maybe using a central management system), the installation performed by yum may need credentials dedicated to system level traffic. If the user’s password used for the proxy connection changes, the configuration needs to be updated in order to work properly.

All repositories are external

Our system reaches the default Red Hat repositories trough the proxy, and we have no internal repositories. On the other hand, any other programs that use the network do not need nor should use proxy. In this case we can configure yum to access all repositories using proxy by adding the following lines to the /etc/yum.conf file, that is used to store the global yum parameters for the given machine:

proxy=http://proxy.foobar.com:8000
proxy_username=foouser
proxy_password=secretpass

In this case keep in mind this configuration will break on password change as well. Any new repositories added will be reached trough the proxy, if there is no override in place on the repository level.

Some repositories are external

The setup may be a bit more complicated if there are external and internal repositories the same time – for example, your servers able to reach the vendor’s repositories trough the open Internet, using the corporate proxy, and the same time they need to access the internal repositories containing software developed and packaged within the company, that are strictly for internal use.

In this case you have to modify the setup on a per repository basis. First set the proxy globaly for yum as all repositories where external, explained in the previous section. For the internal repositories, open each file containing external repositories under /etc/yum.repos.d directory, and add the proxy=_none_ parameter to the internal repository configuration. For example:

Disabling proxy for internal repository

Disabling proxy for internal repository

Conclusion

Proxies provide security and accountability, but sometimes can make our life harder. With some planning and knowledge of the tools available, we can integrate our systems with the proxy so they can reach all data they are intended to, in a way that complies with our proxy settings.

If you have many systems need to reach the same repositories outside the corporate firewall, always consider to mirror these repositories locally, saving a lot of bandwidth, and making the install or upgrade of the clients independent of the world outside of the local network, therefore making it more error-prone. You can set proxy settings on the machine(s) mirroring, and leave all other machines off the public internet at least from the yum perspective. There are central management solutions that provide this functionality, both open source and paid flavor.