Create your own yum repository

Vincent Danen explains how to create your own yum repository with the createrepo tool. One thing it allows you to do is to distribute specialized packages within an organization.

The standard RPM package management tool in Fedora, Red Hat Enterprise Linux, and CentOS is the yum package manager. Yum works quite well, if a little bit slower than other RPM package managers like apt4rpm and urpmi, but it is solid and handles dependencies extremely well. Using it with official and third-party repositories is a breeze to set up, but what if you want to use your own repository? Perhaps you manage a large computer lab or network and need to have -- or want to have -- certain packages available to these systems that you maintain in-house. Or perhaps you simply want to set up your own repository to share a few RPM packages with the world or just your friends.

Creating your own yum repository is very simple, and very straightforward. In order to do it, you need the createrepo tool, which can be found in the createrepo package, so to install it, execute as root:

# yum install createrepo

Once the package is installed, you can begin creating your repository. You will also need some RPM packages to create the repository with. Decide where you want to store your repository; let's say, /var/ftp/repo will be the base directory.

Depending on how particular you want to get, you can dump everything to a single repository or keep things organized. I'm a big fan of organization, so let's assume you will be creating a repository for Fedora 10 and have both i386 and x86_64 packages you want to be made available with it. I would create an appropriate directory tree using the following commands:

# mkdir -p /var/ftp/repo/Fedora/10/{SRPMS,i386,x86_64}

Now copy your i386 packages to /var/ftp/repo/Fedora/10/i386, your x86_64 packages to /var/ftp/repo/Fedora/10/x86_64, and the SRPMS you have (if wanted) to /var/ftp/repo/Fedora/10/SRPMS. To easily automate the creation of the repository metadata, create a shell script called create-my-repo and place it somewhere in your PATH:

for arch in i386 x86_64
    pushd ${destdir}/${arch} >/dev/null 2>&1
        createrepo .
    popd >/dev/null 2>&1

Make the script executable and whenever you run it, it will call the createrepo tool on the two directories: /var/ftp/repo/Fedora/10/i386 and /var/ftp/repo/Fedora/10/x86_64. Once this is done, your repository is ready for use.

If /var/ftp is the available FTP root, then would be the download URL for the i386 packages. To make this available to the other client systems, create a yum repository configuration file called /etc/yum.repos.d/my.repo with the following contents:

name=My Repository

This file can be used on both i386 and x86_64 clients due to the "$basearch" specifier. It will be enabled the next time "yum update" is run.

Creating your own yum repository is very easy and very straightforward, and is a great way for administrators to distribute specialized packages within an organization.

Get the PDF version of this tip here.

Delivered each Tuesday, TechRepublic's free Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!


Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.


Creating a local YUM CentOS repository is very easy. If you several servers and workstations in your environment, it's a good practice to create your own local YUM repository. This gives you more configuration control on what goes on your systems. I found the following step-by-step procedure to create a local CentOS YUM repository.


so, where is i386 package? CD-install or /usr/bin/i386? i don't know steps you do. you can tell clearer for me about it ! thanks you. and have error: [Errno 4] IOError: [Errno ftp error] timed out Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: myrepo. Please verify its path and try again. help me!


Actually, it's come to my attention that using "createrepo -d" is better as it also creates the sqlite database which makes stuff faster, so I would change the script noted from saying "createrepo ." to "createpo -d .".


Thanks for the practical tip. This is the way to go if you have different machines running the same distro version. I guess it's faster to make yum retrieve from your intranet the packages already downloaded on one machine... Any suggestions for automatically moving packs in /var/cache/yum to this kind of personal repo ? apart from a custom shell script run by cron... ?


you can also synchronize your repository with Fedora for example with rsync command.


Creating a mirror of a repository is not be best solution for your case. If all you want is to speed up the repository access (and/or reduce bandwidth usage) then setting up a proxy cache (e.g. squid) on your local network and configuring yum to use it is the bets solution. This way, only the needed files will be transferred, and only once, even if several systems request the same file.


That is the best suggestion. =) You could always just mirror the upstream repository locally and point all the clients to it. Might not make a lot of sense if you only have a few machines and/or have bandwidth constraints, otherwise that might be more hands-off. But a custom shellscript is pretty easy... cronjob to download all available yum updates, move them to the repository, run createrepo, then do the yum update (may remove them from the cache otherwise I think, you'd have to check to make sure). I think you could probably do that in 4-5 lines of bash.


Even if you have only a few machines, mirroring upstream repositories and building from those locally is worthwhile doing. It's the only way to accurately version control your local system builds and updates. i.e. mirror from upstream to a local repo and freeze. Make a second copy of that repo sometime later and then sync up. Wash rinse repeat. If you just rely on the upstream repositories, then you leave yourself exposed to upstream changes between builds, where a system you build a month from now will very likely have a different mix of package versions than a system you build today. If todays system is your test environment and the next system is production, then the production will be different from test, and your test was a waste of time. So always create your own repos, keep multiple versions and build your systems from them. If you want to get really flash, and you're prepared to live life on the bleeding edge, try out Spacewalk. You can achieve the same effect by mirroring from upstream and then pushing the mirrored packages into a Spacewalk channel. Each time you reposync, create a new channel (increment its name) and push the updated collection into it. A system can be told which version to use by changing the channel associated with its subscription and then scheduling an update (or running yum).

Editor's Picks