Background:

Almost all Software Companies use Yum or a variant of other Package Distribution solutions(like Apt, for example). YUM stands for Yellow dog Updater, Modified. It is written by the Linux community as a way to maintain an RPM-based system, to archive/distribute various versions and utils.

From the perspective of Work Flow, we Admins, create and package new RPM’s and copy them to appropriate yum locations, build the yum index again, the Developers and Everyone will execute a single command from the command-line, that would download the rpm and dependencies and install them on the Developers machine.

Key Advantages:

1) Standardize All Machines in an Enterprise Environment, for example, same jdk at a specific location in all Developer Desktops, Automatically the Flex packages on all developer desktops in one go etc.

2) Standard way to distribute Custom Software Packages.

3)Automatic resolution of software dependencies

4) It comes packaged with Redhat, has both GUI and Command Line versions(most popular), Truly Portable(Runs on all Arch’s)

 

Typical Flow:

In general package installation (when one issues ‘yum install package’) flow is (please note, I suppose there is no local cache, or data in cache has expired):

1. yum gets list of repos from config files

2. yum requests repo mirrors list for each repo (if mirrorlist directive is specified and not baseurl one)

3. yum chooses a mirror (fastest if appropriate plug-in is installed, or random from the list) for each repo

4. yum downloads repo indexes from the chosen mirror for each repo

5. yum combining lists of packages provided by all the repos to the final list

6. yum finds the best package (the one matches name and version or latest)

7. yum builds deps tree

8. yum downloads the package and its deps

9. rpm installs the packages

Setting Up A Central Yum Repository Server:

Chose a Server that has enough RAM, Memory and Firewall Access based on the Avg Load you expect. Its a common best practice to create a user(app name) and user home for each app you host:

useradd yum, passwd yum, su – yum, mkdir -p /home/yum/repositories, cd /home/yum/repositories, yum install createrepo

The above command creates a yum repo which can now be used, Depending on how particular you want to get, you can dump all of your files here, Else, I’m a big fan of organization, so let’s assume you will be creating a repository for Centos and have both i386 and x86_64 packages you have be made available with it. I would create an appropriate directory tree using the following commands:

mkdir -p /home/yum/repositories/centos/5(version of centos)/i386(or x86_64)

Now copy your i386 packages to i386 folder and so on.

Instruct Developers to use repository

Developers can use the repository by editing their /etc/yum.conf file as follows

[company name]

name=someRepo

baseurl=ftp://host.company.com/home/yum/repositories/centos/

enabled=1

To easily automate the creation of the repository metadata, create a shell script called create-my-repo and place it somewhere in your PATH:

To easily automate the creation of updated repository metadata, create a shell script that basically iterates through all of your repo’s and executes “createrepo .” command.



One Gotcha:


If the RPM’s that you are providing are us-signed(true in most cases, unless Internet files), all the Developers need to have


vi /etc/yum.conf -> gpgcheck=0


Automatically Update so that All Machines are in sync :


There is a separate yum utility called yum-cron that All Developers need to install/configure in their machines( If you are using Chef/Puppet, we can quickly put together a recipe/manifest to automate this piece too)


yum install yum-cron


chkconfig yum-cron on


chkconfig yum-updatesd off


service yum-cron start


service yum-updatesd stop


Serving Up the Yum Repositories over a Browser: 


You will just need to create a Apache Virtual Host (among other things) in /etc/httpd/conf/httpd.conf for the Repo’s to be able to be explored in a browser:


Alias /rpm “/home/yum/rpm/repositories”

Alias /yum “/home/yum/repositories”

<Directory “/home/yum/repositories”>

Options Indexes FollowSymLinks MultiViews

AllowOverride None

Order allow,deny

Allow from all

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css

AddOutputFilterByType DEFLATE application/x-javascript

</Directory>


Few Interesting Pointers before I signoff:


To define a custom variable or to override the value of an existing one, create a file with the same name as the variable (without the “$” sign) in the /etc/yum/vars/ directory, and add the desired value on its first line.


For example, repository descriptions often include the operating system name. To define a new variable called $osname, create a new file with “Red Hat Enterprise Linux” on the first line and save it as /etc/yum/vars/osname:


~]# echo "Red Hat Enterprise Linux" > /etc/yum/vars/osname


Instead of “Red Hat Enterprise Linux 6”, you can now use the following in the .repo files:


name=$osname $releasever


Official Yum Documentation:


http://yum.baseurl.org/wiki/Guides


http://linux.die.net/man/5/yum.conf


Yum as a Enterprise Software Deployment Solution:


It is an Interesting thought, but, I dont have any Personal Experience in using Yum as a Deployment Solution, It sure sounds good though. Provided the Yum Deployments are scalable, reliable and traceable(with logs etc)


Here is an example of a Custom Yum Server for Deployments:


https://github.com/ImmobilienScout24/yum-repo-server


Companies that have Desktop Apps/ Low level C/C++ Apps that use rpms to deploy can now use nexus too .. to deploy their Apps with Nexus Yum Plugin ..


https://code.google.com/p/nexus-yum-plugin/


Common Yum Commands for Everyone:


http://yum.baseurl.org/wiki/YumCommands


– Krishna Chaitanya Kurnala