Short Answer
Install the equivalent centos-release package from a centos downloads location; This will enable the CentOS package repos where you can do a yum update or a yum install gcc
Long(er) Answer
With respect to the other answers, I felt a slight more full answer could be given to your question.
CentOS aims to be 100% binary compatible with RHEL, hence CentOS 6.2 packages should install and run on RHEL 6.2;
"CentOS conforms fully with the upstream vendors redistribution
policies and aims to be 100% binary compatible. (CentOS mainly changes
packages to remove upstream vendor branding and artwork.)." http://wiki.centos.org/FAQ/General#head-d29a2b7e61ffc544973098f9dd49fe4663efba50
So you can download the "centos-release" package from a CentOs mirror for the release of RHEL you have chosen; CentOS Mirrors List, and that will install the CentOS-Base repo files to enable the CentOs repositories to work in RHEL.
This migration guide covers some of the processes of migrating from RHEL to CentOS in-place - http://wiki.centos.org/HowTos/MigrationGuide
HOWEVER NUMBER 1
A fresh installation of CentOS is always recommended. There will be some problems, and some package cleaning up required if you mix repositories. This is mainly because its a hack to do this, and its not widely tested.
HOWEVER NUMBER 2
CentOS patch levels do not follow the same naming convention as RHEL patches, due to Redhat restrictions and other naming issues.
So there will be a bunch of problems that occur when 3rd party apps rely on redhat-release or centos-release, or some RHEL derived naming for packages and updates, see here for an example of the RHEL vs CentOS naming problems;
http://lists.centos.org/pipermail/centos/2011-April/110995.html
notes
Fedora is based off different source code branches, and hence different shared libraries and kernel revisions. It's unlikely that any of the compiled packages would work across these distros.
EPEL and rpmforge are typically for software packages rather than base-system packages, hence are unlikely to be of any use for your purposes of resolving dependencies for basic stuff.
Word of caution:
The solution below can be a major security issue because you allow the end user to specify a port to hit on the backend server, hence opening the door to allowing access to ports that shouldn't be visible on the outside.
Some mechanism would have to be in place to prevent unwanted ports - this could also be done in a similar fashion with mod_rewrite to let through anything you want and block what you don't want.
This could be done using Apache httpd mod_rewrite and proxy, the directive would be:
RewriteEngine on
RewriteRule ^/?([0-9]*)/(.*) http://www.example.com:$1/$2 [L,P]
You will need to enable mod_rewrite and mod_proxy. For full documentation on mod_rewrite, you can consult:
That said, it would probably be better to actually set it up with ProxyPassMatch...
ProxyPassMatch "^/?([0-9]*)/(.*)" "http://backend.example.com:$1/$2"
Best Answer
Try the other method of configuring a proxy server for Subscription Manager. This will also make the configuration persistent so that you won't have to specify it every time.
See Red Hat's documentation (not the page you quoted!) for further details.