How to version control a mirrored upstream repository

package-managementrepositoryversion controlyum

I manage many servers that span multiple environments (dev, qa, staging, and production). To help manage these, we have multiple repositories on a local webserver for our applications (e.g. app_1_el6, app_2_el7, etc.). We also mirror several upstream repos which provide dependencies for our custom rpms (e.g. EL Repo [1], EPEL [2], etc.) to reduce package download time.

Currently, a cron job syncs the our local with the upstream repositories. From time to time, we'll pull in an update that causes a problem (e.g. incompatibility with one of our packages). This ends up causing a lot of pain, which I'd like to avoid.

What'd I like to do is create some sort of version control for our local mirror of the upstream repos. I'd like to make sure, for instance, that if a new package is introduced in an upstream repo that breaks our custom rpms, that I have a way of rolling back or somehow isolating that package. What's the best way to go about this?

[1] http://elrepo.org/tiki/tiki-index.php

[2] https://fedoraproject.org/wiki/EPEL

Best Answer

Michael Hampton referenced an answer that names Katello and Spacewalk, Satellite is the product RedHat offers to accomplish that.

Katello is to Satellite what Fedora is to RedHat (according to this)

Lifecycle environments and content views are what you are looking for in Katello:

Promoting a Content View

Initially a Content View is published to Library as version 1. If there are Content Hosts in other environments that would like to consume this Content View, a version of the content view will need to be promoted to those environments. For example, given the Content View “New Content View”, version 1 of which has been promoted to the Dev environment. Any Content Hosts in Dev attached to the Content View would remain at version 1 until a version 2 is both published and promoted to the Dev environment.

Content view sample http://www.katello.org/docs/2.3/user_guide/content_views/promote_content_view2.png

Content view promoting progress http://www.katello.org/docs/2.3/user_guide/content_views/promote_content_view3.png

Related Solutions

Yum – How to Know Which Yum Repository a Package Was Installed From

With yum-utils installed, repoquery will provide the information you seek (here 'epel' being the repository).

$ repoquery -i cherokee

Name        : cherokee
Version     : 0.99.49
Release     : 1.el5
Architecture: i386
Size        : 8495964
Packager    : Fedora Project
Group       : Applications/Internet
URL         : http://www.cherokee-project.com/
Repository  : epel
Summary     : Flexible and Fast Webserver
Description :
Cherokee is a very fast, flexible and easy to configure Web Server. It supports
the widespread technologies nowadays: FastCGI, SCGI, PHP, CGI, TLS and SSL
encrypted connections, Virtual hosts, Authentication, on the fly encoding,
Apache compatible log files, and much more.

Gitolite Clone Issues – How to Fix Gitolite Clone Not Working on Debian

Being able to access gitolite@server:~/repositories/gitolite-admin.git, but not gitolite@server:gitolite-admin indicates you are not going “through” Gitolite, but just using plain SSH-based access to the gitolite user.

If ssh gitolite@server echo normal access yields normal access, then the key you are using is not restricted to going through Gitolite. If you were going through Gitolite you would see something like bad command: echo normal access.

This can happen if you have a key that you use to SSH into the gitolite user itself and you try to use that same key to authenticate as a Gitolite user. A “normal access” key will be present in gitolite’s .ssh/authorized_keys without any special prefix. The line for a key that is configured to go through Gitolite will start like command="/path/to/gl-auth-command gitolite-username",….

If you need normal SSH-based access to the gitolite user and Gitolite-based access, then you should setup separate keys for those purposes so that you can specify which key you want to use with IdentityFile options in your .ssh/config file (maybe also IdentitiesOnly if you find that ssh is using the “wrong” key just because you already have it loaded in your ssh-agent).

For example:

Use one of your “default” keys (one of ssh’s defaults (e.g. ~/.ssh/id_rsa) or some key that you usually have loaded in your ssh-agent) to access Gitolite (i.e. you have the public key in the active keydir/your-gitolite-user-name.pub).

Generate ~/.ssh/gitolite-user for use in directly logging into the gitolite user. Use ssh -i ~/.ssh/gitolite-user gitolite@server to login. Or, add a custom entry to ~/.ssh/config:

Host gitolite-user
              User gitolite
          HostName server
      IdentityFile ~/.ssh/gitolite-user
    IdentitiesOnly yes

so you can just do ssh gitolite-user to login.

Best Answer

Related Solutions

Yum – How to Know Which Yum Repository a Package Was Installed From

Gitolite Clone Issues – How to Fix Gitolite Clone Not Working on Debian

Related Topic