Most people working with Oracle Linux will have a way of updating systems by using YUM. When using Oracle Linux as a personal workstation or just a private test server it is perfectly good to use the public YUM server from Oracle.
In cases where you have a secured environment running production servers you most likely do not want to use a connection to a external system to get your updates. You would like to have a local copy of the YUM server. In those cases you can create a satellite YUM server. This will make sure that you always have an updated repository locally which is in sync with the public yum server from Oracle.
However, a second reason can exists to have a local YUM server. In cases where you develop your own RPM's and want to make them available to your Oracle Linux machines it is good practice to run your own local YUM server.
Building a local YUM server is quite easy and not a hard task, making the short investment to ensure you have a your own local YUM server for your self developed RPM's or for packages from other vendors needed in your landscape makes much sense.
The below diagram shows on a high level on how your deployment can look like, not including all firewall components and network components you should use to ensure a correct network zone model for security.
Create YUM Repository
Creating a YUM repository takes a number of steps. First of all you need to have a location where you will store the RPM's and the associated repository meta-data. In our case we know we want to make the YUM repository available via HTTP (using NGINX) at a later moment so we create a location like shown below for our company repository.
The next step will be to ensure that you copy all the RPM's you want to include in your company repository to this location. As soon as they are moved to this location you will have to make this into a real repository. For this you will need some tooling installed on your server. You can do so by installing the below RPM's
As soon as you have the required tooling installed you can create a repository by executing the following commands:
That's it? yes, that is it. Nothing more to do. It will go through your RPM's stored and will create the needed information. You will find a new director named repodata which contains all the data needed for remote YUM clients to connects
Configure NGINX
Having your RPM's and the YUM metadata in the newly created repodata is great. However, what you want is to ensure your clients (servers) can connect to the YUM repository (in the diagram located on yum.company.com). To enable clienst to connect you will have to ensure that the location where you store this (in this example /var/www/repos/companyrepo) is available via HTTP.
As we do not need a heavy weight HTTP server we can use for example NGINX. To install NGINX on Oracle Linux you can refer to this blogpost which provide the needed guidance.
As soon as you have NGINX running you need to ensure that it will point to /var/www/repos/companyrepo . As an example you will need to undertake the following steps to complete the configuration of NGINX.
1) Create a file named companyrepo.conf in /etc/nginx/conf.d
2) Edit the file with VI and ensure you have the below information in the file:
Configure Local Servers
As we now have a local YUM server running on yum.company.com and made it available via HTTP we can now configure the clients (servers) to connect to the local YUM repository and make use of it.
Make sure you have the below configuration in a .repo file in /etc/yum.repos.d . You can have other files in this location as well if required however the below content in a .repo file (for example companyyum.repo) will ensure you can connect to the local company YUM repository and use YUM for installing your own RPM's or RPM's from other vendors.
Update YUM Repository
In case you need to update your local yum server and want to add RPM's to it you do not have to go through the enture createrepo procedure. This can, in case you have a very large set of RPM's, take quite some time. In case you only want to add the new files to the YUM meta-data and make them available to users you can issue the below command instead.
Now your server has the new RPM's availabel for YUM users to connect. In case you directly issue a yum command on one of your clients and it is unable to find the new package it might very well be that your client is having a cache of the repository data locally. This will not contain the new package. To make sure your client is doing a fresh grab of the repository data you will have to enforce the expiration of the local cache by issuing the below command on the client:
The time the cache is kept is configured in /etc/yum.conf and by default it reads keepcache = 1 . This means that you might not run into this issue on every client. However, if your client already did an interaction with the YUM server that day it might have a cache that is not expired yet and might not find the package due to that reason.
In cases where you have a secured environment running production servers you most likely do not want to use a connection to a external system to get your updates. You would like to have a local copy of the YUM server. In those cases you can create a satellite YUM server. This will make sure that you always have an updated repository locally which is in sync with the public yum server from Oracle.
However, a second reason can exists to have a local YUM server. In cases where you develop your own RPM's and want to make them available to your Oracle Linux machines it is good practice to run your own local YUM server.
Building a local YUM server is quite easy and not a hard task, making the short investment to ensure you have a your own local YUM server for your self developed RPM's or for packages from other vendors needed in your landscape makes much sense.
The below diagram shows on a high level on how your deployment can look like, not including all firewall components and network components you should use to ensure a correct network zone model for security.
Create YUM Repository
Creating a YUM repository takes a number of steps. First of all you need to have a location where you will store the RPM's and the associated repository meta-data. In our case we know we want to make the YUM repository available via HTTP (using NGINX) at a later moment so we create a location like shown below for our company repository.
mkdir /var/www/repos/companyrepo
The next step will be to ensure that you copy all the RPM's you want to include in your company repository to this location. As soon as they are moved to this location you will have to make this into a real repository. For this you will need some tooling installed on your server. You can do so by installing the below RPM's
rpm -ivh deltarpm-3.6-3.el7.x86_64.rpm rpm -ivh python-deltarpm-3.6-3.el7.x86_64.rpm rpm -ivh createrepo-0.9.9-25.el7_2.noarch.rpm
As soon as you have the required tooling installed you can create a repository by executing the following commands:
createrepo
That's it? yes, that is it. Nothing more to do. It will go through your RPM's stored and will create the needed information. You will find a new director named repodata which contains all the data needed for remote YUM clients to connects
Configure NGINX
Having your RPM's and the YUM metadata in the newly created repodata is great. However, what you want is to ensure your clients (servers) can connect to the YUM repository (in the diagram located on yum.company.com). To enable clienst to connect you will have to ensure that the location where you store this (in this example /var/www/repos/companyrepo) is available via HTTP.
As we do not need a heavy weight HTTP server we can use for example NGINX. To install NGINX on Oracle Linux you can refer to this blogpost which provide the needed guidance.
As soon as you have NGINX running you need to ensure that it will point to /var/www/repos/companyrepo . As an example you will need to undertake the following steps to complete the configuration of NGINX.
1) Create a file named companyrepo.conf in /etc/nginx/conf.d
touch /etc/nginx/conf.d/companyrepo.conf
2) Edit the file with VI and ensure you have the below information in the file:
server { listen 80; server_name localhost; location / { root /var/www/repos/companyrepo; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } }3) Test if you can access this location on yum.company.com with a standard browser.
Configure Local Servers
As we now have a local YUM server running on yum.company.com and made it available via HTTP we can now configure the clients (servers) to connect to the local YUM repository and make use of it.
Make sure you have the below configuration in a .repo file in /etc/yum.repos.d . You can have other files in this location as well if required however the below content in a .repo file (for example companyyum.repo) will ensure you can connect to the local company YUM repository and use YUM for installing your own RPM's or RPM's from other vendors.
[COMPANYYUM] name=Local company YUM repository baseurl=yum.company.com/ gpgcheck=0 enabled=1
Update YUM Repository
In case you need to update your local yum server and want to add RPM's to it you do not have to go through the enture createrepo procedure. This can, in case you have a very large set of RPM's, take quite some time. In case you only want to add the new files to the YUM meta-data and make them available to users you can issue the below command instead.
createrepo --update .
Now your server has the new RPM's availabel for YUM users to connect. In case you directly issue a yum command on one of your clients and it is unable to find the new package it might very well be that your client is having a cache of the repository data locally. This will not contain the new package. To make sure your client is doing a fresh grab of the repository data you will have to enforce the expiration of the local cache by issuing the below command on the client:
yum clean expire-cache
The time the cache is kept is configured in /etc/yum.conf and by default it reads keepcache = 1 . This means that you might not run into this issue on every client. However, if your client already did an interaction with the YUM server that day it might have a cache that is not expired yet and might not find the package due to that reason.
No comments:
Post a Comment