Yum repomd.xml Error

I installed Fedora 11 in a VMware virtual machine from a DVD iso image. After installation, I went on to do yum update and got this message: Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Searching the web revealed one most-recommended solution: check your DNS settings. It turns out, repomd.xml is a file located on the mirror from which you are trying to download updates, new package, whatever. The error message is displayed when yum is unable to either find or get the repomd file.

The first thing you should check is your Internet connection. Maybe try to ping some server (ping -c 3 google.com). If your connection is fine, the issue could be with DNS settings, proxy issues, or maybe the mirror you are connecting to is having problems. One solution I found said they simply waited some hours and it worked. It indicates to me that maybe the mirrors were having a hard time when they first tried but when their load decreased things were ok.

When I checked, eth0 on my Fedora install was disabled. I had to enable it, make sure network card was connected on VMware, brought down the interface and brought it back up. It used DHCP to get a new IP. I tested a ping to a server and it was successful. Now yum worked just fine.

Enable eth0

To enable eth0, I had to change the ifcfg-eth0 file. I ran the following commands:

sudo vim /etc/sysconfig/network-scripts/ifcfg-eth0

And made sure the following two lines were present:



Bring Down Interface and Bring it Up

To bring down my eth0 interface, I ran

sudo ifdown eth0

To bring it back up, I ran

sudo ifup eth0

Why I am Leaning Toward CentOS

I am looking at various options for a Linux distribution these days. Some of them I discussed in my previous post on how to choose a Linux distribution. Here I would like to point out some factors why I am leaning toward CentOS.

Repackaged Red Hat Enterprise Linux

The biggest benefit of CentOS is that it has all the benefits of Red Hat Enterprise Linux (RHEL). You get support from many independent and third-party entities, such as hardware and software vendors. If it says it support RHEL, you can be pretty sure it supports CentOS. This is a big deal in the business world. If you need to have a certain application and it only officially supports RHEL, CentOS gives you the option to use it without too much trouble. Of course, the reason you would use CentOS instead of RHEL is to save on support subscription offered by Red Hat.

We all can see how much good work Red Hat is doing. I would like to support it with my (or my company’s) money. On the other hand, CentOS is doing some good work of making Red Hat’s work available to the masses. They also deserve our support. My compromise, to keep me and the bigwigs happy would be to use CentOS on development and testing servers. Then move to RHEL for production. The boss is happy to pay someone (Red Hat) for production support and you can maybe provide some of that support money to CentOS. Such workflow could keep most people happy.


I am interested in learning more about SELinux and how to best use it to secure computers. CentOS comes with it and gives everyone a chance to utilize its benefits. But why choose SELinux? Well, if it helps me learn more about security while also keeping my computers secure, I am all for it. I am not such a philosophical freak to take sides. Best tool for the job, is what I believe in.


Extra Packages for Enterprise Linux (EPEL) is a repository of software for RHEL which is not “officially” included in RHEL. It gives CentOS the best of both worlds: officially supported packages along with some other packages you may need to get your job done.

RPM Repositories

You can combine CentOS with repositories other than EPEL and get even more packages. These include, but are not limited to, rpmforge and atrpms.


If you are running CentOS, then Fedora compliments your choice on the desktop. So if in my ideal compromise you have CentOS running on development and testing servers, then maybe your desktops could be running Fedora. According to Fedora website, “Fedora now forms the basis for derivative distributions such as Red Hat Enterprise Linux”. In effect, you are trying out a possibly future version of CentOS before it even comes out.

Fedora on its own is a very good distribution. It has quick releases and the newest technology around. What more could you want from a Linux distribution?


If you are in a business environment where you need RHEL, CentOS can be a great resource. If you are not, then CentOS gives you all the benefit of RHEL without the cost. It is a great distribution for different purposes. Combine it with the RHEL-environment, such as Fedora, and you may not need another Linux distribution. Of course, if CentOS is your choice, maybe Scientific Linux deserves some love as well.

Choosing a Linux Distribution

Recently I have had more time to work with Linux. I had been using Ubuntu in some way for two years when I needed to set up Linux on a few years old server. Since I was comfortable with Ubuntu, I thought I might as well go ahead and use it. But then I found out that there were other alternatives as well. This caused a headache which still isn’t resolved to this day. Which distribution is the best to get hands-on, real world experience with?


You have to look at your comfort level when choosing a distribution. If you are familiar with something, even in passing, it would be an easier path to go with what you know. On the other hand, all distributions may be different but they have more in common than there are differences. So learning another distribution style is not as difficult as one might expect.

Hardware Support

If the distribution you choose is not able to function on the hardware you have available, you should not choose it. If you can get it to work, with or without a lot of effort, all the power to you. If, however, you can’t get it to work, you might as well look for another option. I went ahead with Ubuntu on the server because it supported all its hardware out of the box. I did not have to tweak anything or waste a lot of time. On the same server I was unable to install CentOS because Red Hat had dropped support for server’s RAID card in its current distribution.


For what purpose are you using a distribution? Is it going to be for starting out, testing, development, or deployment? For all these scenarios, there are many distributions fitting them just fine. For starting out, a friendly distribution like Ubuntu could work. If you are testing Linux for its feasibility in your environment, just about any distribution would work. A distribution for doing development work should be fast moving with new technology so that you can use it to its fullest extent. If it’s for production deployment, being conservative in your selection is recommended.

Cutting Edge Technology

Some distributions strive to be on the cutting-edge. I count Fedora, openSUSE, and Ubuntu in this category. They release new stuff every few months. So you get to work with what’s new. For example, on Ubuntu, I found Django packages ready to install and work. Since I wanted a package and I found it, I was able to start working. I did not have to jump through hoops just to get to the point where I would be able to work.


Yes, an enterprise version would be more stable and maybe more secure. But it is also less likely to include new technology in an easily accessible format. Taking the example of Django, I have not found any tutorial on the web to install it on CentOS using an RPM package. All tutorials I have read ask you to download and install from source. Yes, it’s the traditional way to do things but if package management is the future, we should look for packages first and source code later. Now if I am developing and deploying an application developed with Django, I want to have the peace of mind that I installed a package that had been tested to work well with the whole operating system, and not something I installed without knowing how it would turn out.

To me this is the most important point after hardware support. I am willing to learn a whole another distribution if it is enterprise level with great hardware support but also keeps up with new technology. Since not one distribution will always fill these requirements, we have to look at the best tool for the job at hand.


I was shocked to learn a few days ago that Ubuntu server’s default firewall policy was to accept all traffic. CentOS, on the other hand, has a pretty aggressive firewall policy. Combined with recent scandal of Debian and OpenSSL, it has dented my confidence in Ubuntu. It’s not that Ubuntu is insecure, it’s just the appearance of security in the ecosystem is absent (to me, at least). It’s also not that these things cannot be rectified by me, it’s that why would I need to take an extra step when a prudent decision could do it for me in the first place.

Another aspect I look to is being root. Does one have to actually be root or would sudo do? I like the sudo model better since it forces you to actually type your permission when doing critical work. Yes, if you are careful su and su - would work as well as sudo. But I like the added carefulness of sudo. So the first thing I do after installing a distribution is to see if it has sudo and then enable it for at least one user.


Support is a very important part of decision-making process. Support may be of three kinds: distribution creator, third-party professional, and community and friends. Support includes help as well as software updates. One can get help from many sources, and community is an essential part of this support ecosystem. It can get you started and get you out of trouble. Almost all (ok, maybe all) distributions provide software updates. Then there is an extra level of support which we know as enterprise or corporate support (think Red Hat). It is provided by either the creators and maintainer of the distribution or from third-party entities.

For a home user, software updates and community support should be sufficient. For a business, however, ‘corporate’ support is essential on production systems. Businesses like to pay someone to get extra insurance in case it is needed. If a server is essential to business operations, it is very important that the team running the server knows what it is doing, has community support for minor issues, and corporate support when things go really bad.

Red Hat, Novell, and Canonical provide this kind of support as they create their distributions. Of course, if you have a good team running your servers, you may not need to get corporate support. But if your manager is a non-technical person, she will most probably require it. And if it’s not your money being spent, why argue?


This was meant to be a discussion of factors I would look into when choosing a distribution. Nothing more, nothing less.

Disclaimer: I have edited, and will edit, this post as new arguments come up.

Little Linux Commands

In this post I shall add little commands that one may forget but could be very useful. My goal is to collect commands for as many distributions are possible. Following distributions are very closely related to each other and, unless otherwise noted, commands specified for one may be run on all of them without modification.

Red Hat: CentOS, Fedora
Ubuntu: Debian

So, for example, if a command is given for Red Hat, it may be run on CentOS and Fedora. If, however, a command is given explicitly for CentOS, it may or may not run on Red Hat and Fedora. If no distribution is given, it is very likely that the command runs on all distributions.

Find Distribution Release Version

If you want to know the release version of a distribution, you may use following commands.

Red Hat, Ubuntu: tail /etc/issue
Red Hat: tail /etc/redhat-release
SUSE: tail /etc/SuSE-release
Ubuntu (gives more detail): tail /etc/lsb-release

Find Gateway of Network Interface

All:netstat -rn


A runlevel determines what services are started when computer boots up. To find at what runlevel your computer is running at this moment, type the following.

All: runlevel

Output should look something like

N 5

Where N is the previous runlevel and 5 is current runlevel.

Packages Installed

Red Hat: yum list installed
Ubuntu: dpkg -l

Split Files

If you want to split a file into many smaller parts, use this (hat tip: How do I open a 2.5 gig .xml file?):

split -l 50 myfile.txt mynewfile

Show All Users

If you want to list all users of the system, whether they are logged in or not, run the following command. It uses the cut command on the /etc/passwd file.

All: cut -d: -f 1 /etc/passwd

Hat tip for this trick: How to list all your users; man cut.

Lock root

If you want to lock or disable root user, or any other user for that matter, do the following (replace root with the user you want to lock):

All: sudo passwd -l root

Another way to lock a user is to do the following:

All: sudo usermod -L root

Similarly, to unlock a user:

All: sudo usermod -U root

Securely Copy Directory from Remote Server

If you want to use SCP to copy a whole directory from a remote server to your current directory on local machine, do the following:

All: scp -r user@host:/home/me/mydir/. .

The first dot in the path of the remote server tells it to copy all files and folders in the /home/me/ directory, even hidden files and directories. If you use asterisk instead of dot, it will not copy hidden stuff. The second dot means copy everything to the current directory on local machine.

Hat tip for this trick: Moving /home data from old system to new Linux system.

Support for Virtualization in Processor

To see whether your current processor supports Intel-VT (vmx) or AMD-V (svm) virtualization, run the following:

All: egrep -e 'vmx|svm' /proc/cpuinfo

Thanks to CentOS 5 Xen Virtualization.

What packages are in package group

In Debian, tasksel has various groups of packages, such as Standard, Laptop, etc. But what do these groups contain? Thanks to a post by yankovic_yeah, we know.

Ubuntu: aptitude search $(tasksel --task-packages standard)

CentOS 5 Post Install Customization

I have collected these tips after testing them on Fedora or CentOS, but not necessarily on both. I have actually merged the article ‘Fedora 7 Post Install Customization’ with this one since CentOS and Fedora share many, many things. The Fedora article has been removed from the site. So you may want to update your bookmarks. These tips may be used as is or with some modification on almost all Red Hat-based distributions.

Remote Desktop Through VNC

This tutorial deals with setting up a machine for remote access. That is, other machines are able to access this machine through VNC. First, install a VNC server using the following command:

yum install vnc-server

To install VNC client,

yum install vnc

Open ports 5900 and 5901 on the firewall. If you want more than one VNC sessions to occur simultaneously, then open ports for those in your firewall. Say you want four simultaneous sessions. Then you would want to open ports 5901, 5902, 5903, and 5904. You may open ports in GUI or via command line.

Now make sure all users have their own .vnc directory in their home directory. For example, ‘testuser’ should have a /home/testuser/.vnc/ directory. If not, create one using

mkdir /home/testuser/.vnc/

Now setup VNC passwords for each user you want to allow VNC for. For example. if you want user ‘testuser’ to be able to VNC, log in as ‘testuser’ and run command


It will ask you to enter and verify your password. Remember, each user needs to set up their own password with this command. It will store password in /home/testuser/.vnc/passwd file.

Check to see if you have xstartup file in /home/testuser/.vnc/ and if not, create one using

vim /home/testuser/.vnc/xstartup

And make sure it looks like this:

# Uncomment the following two lines for normal desktop:
exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &

xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
startx &
exec gnome-session &

I chose GNOME because I use it on CentOS. If you prefer KDE, just change gnome-session to kde-session. Also, you have to make this file executable, using the following

chmod u+x /home/testuser/.vnc/xstartup

If you do not make this executable, and once VNC is all setup, you may only get a gray screen with a big black mouse pointer. If you make this file executable, this problem should not occur.

Another reason you may get this gray screen is when the character encoding of the file may not be what the scripts are expecting. To remedy this situation, make sure you use files created and modified on Linux. I had the same problem when I created a file on Windows and downloaded it in Linux. When I created the file in Linux, the problem went away.

Now, as root, you need to edit one file

vim /etc/sysconfig/vncservers

And make sure it has the following lines:

VNCSERVERS="1:testuser 2:otheruser 3:moreuser"
VNCSERVERARGS[1]="-geometry 1024×768 -depth 16"
VNCSERVERARGS[2]="-geometry 800×600 -depth 16"
VNCSERVERARGS[3]="-geometry 1024×768 -depth 16"

What we are doing here is setting up three VNC sessions for three users: testuser, otheruser, and moreuser. Add as many users as you want here. Remember, also open ports in firewall for each VNC session you open.

Be careful. After first installing VNC server, VNCSERVERARGS[1] will not look like this and would probably have flags set so that it doesn’t listen on network. You have to make sure your file looks like what has been shown above. Be careful that -depth is at least 16, not 8. Otherwise it may not work properly. Of course, you may set an appropriate screen resolution, not necessarily what has been set above.

Now you are ready to start VNC server as root.

service vncserver start

To make sure VNC starts up whenever the computer starts, do the following

chkconfig vncserver on

It should give you an OK for all VNC sessions you added in /etc/sysconf/vncservers. You will connect using your VNC client using the following address:

yourhostname :1

or you could use an IP address :1

Where :1 is the number chosen for the user in /etc/sysconf/vncservers. When asked, enter password for that user. The benefit of this method is you do not need to enable auto login to be able to use VNC.

I have to thank the following for helping me learn and also write about this issue: Tutorial: VNC; Set up the VNC server in Fedora;

Change Hostname

To change hostname to another, you need to take care of two things: change the /etc/hostname file and the /etc/sysconfig/network file.

sudo vim /etc/hostname

If there is already a name, replace it with the new one. Or if the file is empty, just add the new name.

sudo vim /etc/sysconfig/network

Change your old hostname to the new one.

sudo /bin/hostname -F /etc/hostname

Although you should not need to reboot, even if you do, the new hostname should show up every time. You may even logout and then login to see the new hostname in effect.

I had to learn these things the hard way but now I am able to share them with you.

Unable to Access Internet

If you are using static IP address and are unable to access the Internet while LAN access is going smoothly, try this: add a routing rule using the Network GUI with the following values. Of course, you would need to change the gateway’s IP to whatever IP your own gateway is using.


Allow a User to SUDO

I took this step as root, using instructions found in a good tutorial: Configuring SUDO.

su --login -c 'visudo'

Then I uncommented the line saying

# %wheel ALL=(ALL) ALL

and changed it to

%wheel ALL=(ALL) ALL

Also, I added the user I wanted to allow to use sudo by adding the following line below the line root ALL=(ALL) ALL. So now the file read

root ALL=(ALL) ALL
newuser ALL=(ALL) ALL

The user ‘newuser’ was then able to use sudo and it asked for a password every time.

Useful Resources

If you are looking to trim your CentOS install, you may find Building a Tiny CentOS Installation to be very useful.