ObjectiveOur 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
RequirementsPrivileged access to the system
- # - requires given linux commands to be executed with root privileges either directly as a root user or by use of
- $ - given linux commands to be executed as a regular non-privileged user
IntroductionIn 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
yumto 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.
BLUE SKY STUDIOS are looking for Linux Administrator to maintain and support the Studio's 450+ production Linux workstations, including daily interactions with the Studio’s digital animation artists.
LOCATION: Greenwich, Connecticut, USA
Tutorial setupIn 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
foouseras username and
secretpassas 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 proxyIf 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:
You can set the
https_proxyvariable the same way.
Until you terminate the session, or
unsetthe exported variable, the
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 proxyIf 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.ddirectory, 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/profileor a separate file under the
/etc/profile.ddirectory, using your favorite text editor:
You can set these a per user level as well (for example in
export http_proxy=http://foouser:firstname.lastname@example.org:8000 export https_proxy=http://foouser:email@example.com:8000
.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
yumand 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
yummay 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 externalOur 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
yumto access all repositories using proxy by adding the following lines to the
/etc/yum.conffile, that is used to store the global yum parameters for the given machine:
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.
proxy=http://proxy.foobar.com:8000 proxy_username=foouser proxy_password=secretpass
Some repositories are externalThe 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.ddirectory, and add the
proxy=_none_parameter to the internal repository configuration. For example:
ConclusionProxies 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
yumperspective. There are central management solutions that provide this functionality, both open source and paid flavor.