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?

Comfort

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.

Purpose

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.

Enterprise

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.

Security

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

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?

Conclusion

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.

iptables Introduction

I have always wanted to learn how to write iptables rules for Linux. In my quest, I have used these resources to teach me what little I have learned so far: Hardening Linux; Iptables Tutorial; Ubuntu Setup;. This is an introduction to iptables.

First, we need to learn how to write an iptables rule. The general format would be

iptables table command chain match target

There are three main tables: filter, nat, and mangle. filter is considered to be default if you do not specify a table. So your first rule would start to look like

iptables -t filter

Commands include, but are not limited to, append, insert, delete, and replace. Let’s say we are adding a new rule so our command now looks like

iptables -t filter -A

There are three main chains: input, output, and forward. Input deals with all traffic incoming to the server, output is traffic generated by server, and forward is traffic not for the server but for some other machine. Let’s say we need to deal with incoming traffic. Now our command looks like

iptables -t filter -A INPUT

Matching is the heart and soul of the rule. The most common things in matching are interface, source IP address, source port, destination IP address, destination port, and protocol. Let’s say our example deals with incoming interface eth0, for HTTP from any computer. Our command may look like

iptables -t filter -A INPUT -i eth0 -dport 80 -p tcp

Since any computer may connect, we have left out source IP and source ports.

Last part is target. Most common targets are accept, reject, and drop. Since we are looking to accept HTTP traffic in our source example, we will use accept. Now our command looks like

iptables -t filter -A INPUT -i eth0 -dport 80 -p tcp -j ACCEPT

We have created our first iptables rule. It will accept all incoming web traffic on port 80. See, it isn’t too hard to get started with iptables.

Location of iptables Rules in CentOS

CentOS stores its rules in /etc/sysconfig/iptables

Location of iptables Rules in Ubuntu

By default, Ubuntu has a policy of accepting all incoming traffic. Therefore, there are no default iptable rules. However, if you want to create your own, then put them in a file and modify /etc/network/interfaces by adding the following line:

pre-up iptables-restore < /etc/iptables.up.rules

where iptables.up.rules is the file where all rules were stored.

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

vncpasswd

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:

#!/bin/sh
# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
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

192.168.168.100 :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.

address: 0.0.0.0
netmask: 0.0.0.0
gateway: 192.168.1.0

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.