Linux Install Marathon Followup

Recently I have been trying out various distributions in parallel, following up on the plan presented in “Linux Install Marathon”. However, as is obvious, I did not follow the plan perfectly. Reviewing my stance it appeared that there’s another dimension to the question of which distribution someone should use. Here I will make a sweeping generalization and classify users into two main groups: (1) those who want to learn more about their Linux; and (2) those who want to manage their Linux as means to a goal of running one or more applications. There’s evident difference between these two classes of users. I would include hobbyists in group (1), home and work users in both groups (1) and (2), and individuals and enterprises needing server ecosystems in group (2). I consider myself a part of both groups equally but recently, due to time and other constraints, I have been 75% in group (2) and 25% in group (1). This is the reason why I am trying out different distributions in parallel instead of trying them out one at a time for a certain period of time.

If you need to run certain applications on “Linux”, then you should approach distributions asking this question: how do you, compared to another distribution, make it easier for me to run this application? Now there are two general types of applications: (a) need to be updated in a short span; and (b) need to be updated over a longer period of time. If your application is in group (a) then a distribution that provides regular, short-term updates/upgrades might be more suitable. And if your application is in group (b) then a distribution with a longer life-cycle might be more appropriate.

Usually you would not be running a single application. There’s a whole ecosystem that you need to run any given application. For this reason, you need to prepare a list of all needed applications and compare each distribution against this list. No distribution will be 100% compatible with your list so this is where you need to change tactics again. If two or more distributions in the same family can cover all (or most) of your applications, then this is the best scenario. However, sometimes distributions from different families will cover your needs better. This is when you have to make a decision on whether you want to compromise on your chosen applications or you want to dive in to diverse distribution families.

The first step in determining if a distribution will make it easier for you to run an application is to check whether the application is provided as a package. This package could exist in an official, semi-official, or non-official repository. If it doesn’t exist in an easily installable package, first look at another distribution. If you really want to use the current distribution, and do not want to explore another, then check if the distribution makes it easy to compile and install the application.

Let’s take the example of bug tracking applications Roundup Tracker, Bugzilla, and Request Tracker. By using aptitude, urpmi, yum, and zypper, I looked in various distributions (Fedora, Debian, Ubuntu, Mageia, PCLinuxOS, and openSUSE) if packages were provided for them. The results were thus: Roundup Tracker (Fedora 16, Debian testing, Debian stable, Ubuntu 11.04), Bugzilla (Fedora 16, Debian stable, Mageia 1, Ubuntu 11.04), and Request Tracker (Fedora 16, Debian testing, Ubuntu 11.04). Within the same class of applications, some of the handful of distributions I tested provided packages.

But just one class is not enough for me to make a decision. Let’s take a look at another class: web servers. I tried nginx and Apache 2 and results were thus: nginx (Fedora 16, Debian testing, Mageia 1, openSUSE 11.4, PCLinuxOS 2011.07 KDE mini, Ubuntu 11.04) and Apache 2 (Fedora 16, Debian testing, Mageia 1, openSUSE 11.4, PCLinuxOS 2011.07 KDE mini, Ubuntu 11.04). In this class of applications, all distributions I tested provided packages.

This is where you get a better idea of which distribution to keep in your prospective list and which one to dump. Continue doing this for all classes of applications and all applications in these classes that matter to you. You will come to a conclusion on which distribution is best suited for the kind of work you want to do.

Linux Install Marathon

I was reading Virtualbox Additions and the post left me with an idea: why not force myself to try different distributions?

Now, I have tried various distributions previously, some for a short period and others much longer. The list includes, in no particular order, Debian, Ubuntu, CentOS, Fedora, and Linux Mint. I have used these as both desktops and servers, and am fairly comfortable using them. If you look at this list from the perspective of polishing up your resume, CentOS, Ubuntu, and Debian are very good choices. A prospective employer usually requires some experience with these (and some other) major distributions if they are looking for Linux experience. So if your first goal is to use your Linux experience for employment enhancement, then you should definitely try these out.

However, the world of Linux does not encompass or end with these distributions alone. There are many, many others. Most of them, I believe, belong to a “family” of distributions. From the post I mentioned at the beginning, one gets a sense of these major families of distributions (again, in no particular order): Debian, Red Hat, Gentoo, Arch, Slackware, Mandriva, and SUSE. These families consist of numerous distributions, each sharing the same heritage if not parents and grandparents.

Looking at the list of distributions I mentioned earlier, I have been mostly limited to Debian and Red Hat families. With so many other families available, it’s time for me to branch out. Looking at the characteristics of various distributions, I am not ready for something intensive right now. All I want is for something to work well out of the box. As I gain experience with more distributions, I would feel more comfortable with something as involved as, say Arch.

So what’s the plan of action? First off, pick a family for a whole year and stick with it. This is why this post has the word “marathon” and not “sprint” in it. It takes a full year of hard work, frustration, realization, and exuberance before one can truly say if the time spent with the distribution family was really worth it or not. So your (and my) first step should be to pick a family that has some good out-of-the-box distributions and try those out first. These are usually more downstream from the head-of-the-family distribution. For example, Linux Mint is based on Ubuntu while Ubuntu is based on Debian. Linux Mint is friendlier than Ubuntu and Debian. So pick Linux Mint and use it. As you gain experience and confidence, go to Ubuntu, and then to Debian. Once you are familiar with the style of the family, you proceed up the chain toward more trying challenges.

Sometimes a year may not be enough, sometimes it may be a long time. So adjust your schedule accordingly. But try to stick it out. I would recommend installing in a virtual machine first and using it for a while. You may want to install numerous times with different configurations. When you feel that you can handle the distribution, go ahead and install it on your physical machine.

Almost all distributions allow you to run them as servers and desktops. A distribution may be focused more on the server or on the desktop but it usually would not prevent you from using it both ways. Keeping this in mind, you might want to run the same distribution in these two ways. This will help you evaluate better the pros and cons of each distribution.

Now, there are a lot of distributions in these numerous families. I recommend picking the most popular distributions in each family and sticking with them. The reason is that there is likely to be more support available if the distribution is popular.

Given these categories to consider, how do I plan on moving ahead? For this year, I pick the Mandriva family. I will start with Mageia. Later I have my eyes on PCLinuxOS and Mandriva itself. Next year I will very likely try the SUSE family. In short, the time has come for me to explore the depth and breadth of Linux distribution offerings. I will share my experiences as I make progress.

Do not install Linux alongside Windows

Yes, don’t do it IF you are doing it for the first time (or are still inexperienced) AND you really, really can’t risk losing your Windows partition. Yes, there are multiple ways to recover if your Windows is messed up during the process but if you can avoid it, why not? The best thing in this situation is to install Linux on a separate drive (hard drive, flash drive, etc.) and keep your Windows partition untouched.

If you really want to try dual-boot or even multi-boot, then backup your data. After backing up, verify your backup. Make sure you have access to installation media for Windows (including license key) and applications you already have installed. Be prepared for the worst.

This advice is for the inexperienced amongst us. If you are willing to risk and learn from unintended consequences, then by all means go ahead. But if you are not willing, then better safe than sorry. Having said that, I have not had a problem installing Ubuntu along side Windows and Mac OS X in the last two years on many different types of hardware. This shows that multiple-boot can be done without problems most of the time. If I can do it, anyone else can surely do it. But when I do it, I always prepare myself to handle bad situations. You should, too.

Convert pst to mbox

I was helping a friend migrate from Windows to Linux. I tried to install Outlook 2003 in Wine. It installed without problems, was able to read his original pst file, but when trying to create an email account so he could begin sending and receiving his emails, the screen was blank. The next issue was bringing in all his emails from Outlook 2003 to Thunderbird 3 so that he could use it. This is where readpst comes in handy. You can use it to convert pst to mbox which you can then copy/paste into your Thunderbird profile.

Install in Debian: sudo aptitude install readpst
Install in Fedora: sudo yum install libpst

Then you run the following command to convert your pst into mbox:

readpst -r Outlook.pst

Installing Linux on Dell Inspiron Mini 1012

I got a Dell Inspiron Mini 1012 recently just to use as a machine to distro-hop. I tried Live CDs of many distributions and following are my observations. Since there’s no CD or DVD drive in the Mini 1012, I used Windows, UNetbootin, and a Patriot Razzo USB thumb drive to create my installation media.

PCLinuxOS 2010

I downloaded the GNOME and KDE versions. All buttons worked in the KDE version, including brightness and audio keys. Wireless was detected automatically and I was able to connect to my home wireless network without problems. The only problem was that audio was too low, even after maximizing the audio level. Thinking it might be an issue with KDE, I ran the GNOME version.

In GNOME all keys worked except the audio keys. Audio itself was very good, unlike in KDE. But no matter what I tried I could not get the audio keys to work. Again, wireless worked out of the box and I was even able to watch videos in You Tube without having to install Flash. But because of the problems with either too low audio or the audio keys not working, I decided to skip PCLinuxOS.

gNewSense

I was aware that gNewSense provides free software only and would not work with hardware devices requiring proprietary drivers. I still gave it a shot. As I had expected, wireless did not work and I found no option to actually get it to work. Kudos to the project for sticking to their principles but I do need to use wireless. All keys, such as brightness and audio worked out of the box. I had to skip it because of the wireless issue.

Linux Mint

I downloaded Linux Mint 9, based on Ubuntu. All keys worked but wireless would not work. Since I have read in many places that Mint is supposed to be a friendlier version of Ubuntu I was a little disappointed. So I just left it at that.

Peppermint Linux

This is, I believe, based on Linux Mint. It had the same issue with wireless card not working. I skipped it for the same reason.

openSUSE

I downloaded the 11.2 version but when booting I got an error message saying Could not find kernel image: gfxboot. A little searching showed (Could not find kernel image: gfxboot) that the issue is with using UNetbootin to create the installer on a USB drive. I didn’t feel inclined to follow the official method and so skipped it.

Mandriva

I tried to get Mandriva to boot but it would get stuck on a splash screen of some sort. I searched around a bit but did not find a solid way to solve the problem. The result: skip it.

Ubuntu

Since Dell has been working with Ubuntu I expected it to work flawlessly. So instead of playing around with the Live CD I just went in there and started installing Ubuntu 10.04. The first thing that impressed me was during disk partitioning it recognized the original Windows installation and prepared a plan to keep it while installing Ubuntu. Once I booted for the first time I was shown a message saying there was a proprietary driver available for my wireless card. I installed it and everything worked from. All keys were working as expected. I kept it around for a few days and then decided to move on.

Fedora

Soon after I installed Ubuntu Fedora 13 was released. I booted its Live CD and found the same repeated problem: wireless card would not work. I searched around and found a solution: install RPM Fusion repo and then follow the instructions of How To: Wireless LAN with Broadcom BCM4312 in Fedora 11. This basically involved running the following command and then re-booting the machine: sudo yum install broadcom-wl wl-kmod.

During installation Fedora also found the Windows and Ubuntu partitions and allowed me to install over Ubuntu while keeping Windows intact.

I installed Flash using the instructions at Fedora 11 Flash. And from there You Tube videos started working. All keys worked out of the box; there were no issues with audio either.

Conclusion

As of this writing I am happily running Fedora 13 on my Dell Mini 1012. Although I tried a lot of distributions, I didn’t spend as much time trying to get them to work on this machine as I did with Ubuntu and Fedora. For this reason I would give all of them a try sometime in the future. Ubuntu has a netbook remix which I tried as well, I prefer the simple GNOME with just one bar at the top to better utilize my netbook’s screen space. If you have the same or similar netbook please share your experience with distro-hopping on it (if any) and which distro you are happily running these days.

lspci Output

I ran lspci and following is the output.

00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge
00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller
00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
07:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)

An Introduction to Linphone

I have been looking for a softphone for some time now with two requirements: (1) easy to use GUI; and (2) can easily be used from command line. Many softphones have great GUIs, which are easy to use and very friendly. The second part, easy to use from command line, was a tricky requirement. The idea is to make a complete call from the command line in an interactive way. For example, dial a number, enter options to any IVRs, and then hangup once done. However, I had another requirement: be able to script this whole thing as well.

Linphone is a softphone that met my requirements. It is very easy to use. I was able to use its GUI to create SIP accounts and register with Asterisk and FreeSWITCH, and make calls easily. But there are two things which make this the complete package for me.

The first is linphonec. It’s a command line program which lets you make calls, etc. interactively. Just run the program, it registers with the appropriate servers, and then you can issue commands to make and control calls.

The second is linphonecsh. This is what finally sold me on this product. Using some very simple steps, one can script the whole behavior of one (or more, if desired) calls. Linphonecsh is actually a daemon for linphonec. You can read how to control it from Control a linphonec daemon from scripts. Although that’s the official page, for those of us too lazy to click a link, below are the main steps:

Start the daemon: linphonecsh init
Register with SIP provider: linphonecsh register --host mysipprovider.net --username 100 --password mypassword
Check status of registration: linphonecsh status register
Call a number: linphonecsh dial "sip:1235550000@mysipprovider.net"
Disconnect call: linphonecsh hangup
Stop the daemon: linphonecsh exit

I had a problem. I wanted to register Linphone to an Asterisk server on the LAN. I used the following command to register (I am omitting the init, etc. as they are understood).

linphonecsh register --host 10.10.1.10 --username 100 --password mypassword

But linphonecsh status register would show register=-1. I tried many things but nothing worked. Searching led me to Linphonecsh register problem. I didn’t really understand what I was doing wrong. I finally figured it out.

If you look at ~/.linphonerc file, you will notice that the word realm is used. For me it was realm="asterisk". The way I understand it, realm in the file is the same as --host in the register command. In other words, if realm is “asterisk” then --host should not be an IP address but it should be a hostname.

With this idea in mind, I created an entry in /etc/hosts file for 10.10.1.10 mapping to asterisk. And I modified my register command to the following. It worked!

linphonecsh register --host asterisk --username 100 --password mypassword

So if you are having problems registering linphonecsh to an Asterisk server, try this. Maybe it will solve your problem. I mean, it’s not just with Asterisk; the solution may work for other servers also. Of course, if the server is not on your LAN, you should use its domain name instead of IP for --host.

Secure Your SSH

So you have your SSH server on Linux up and running and you are able to login easily. But you may still be vulnerable to attacks on your SSH server, primary being brute force dictionary attacks. This post will point out some areas of vulnerabilities and also advise some solutions.

Only Allow Certain Users to Login via SSH

Your Linux machine has many users built into it. But only some of them need to have access to the server via SSH. If we can lock down a list of such users, we can reduce the number of users an attacker can pretend to be. For example, there are only three users on my machine who need to login. The good thing is that SSH allows you to setup either a list of users or a group of users who are allowed access.

I prefer the group method. The idea is to create a new Linux group and add users to it. If a user is a member of this group then he/she can login via SSH. If they are not a member they cannot. Then in the sshd config file we can specify this group as being the only one with access. Here’s how we do it.

Create a group
sudo groupadd mysshgroup

Add an existing user to this group. Thanks to Howto: Linux Add User To Group.
sudo usermod -a -G mysshgroup codeghar

Allow access only to this group in /etc/ssh/sshd_config file by making sure the following line exists in it.
AllowGroups mysshgroup

Disable root Login

Everyone who knows Linux knows there’s always a root user. So all the attackers out there know they just need to break its password to gain (complete) access to the system. What if we disallow root from logging in directly? This cuts down on a huge threat to your system.

Disable root login in /etc/ssh/sshd_config file by making sure the following line exists in it.
PermitRootLogin no

Disable Empty Password

Now that we have disallowed all users except those in the mysshgroup group to login, we have to make sure these users do not use empty passwords. If we don’t restrict this, a user, say codeghar, might have an empty password and an attacker can login very easily. We don’t want that.

Disable empty passwords in /etc/ssh/sshd_config file by making sure the following line exists in it.
PermitEmptyPasswords no

Allow Public Key Authentication Only

This means that we disable password-based authentication and only use public key authentication. This completely eliminates dictionary attacks because we just don’t use passwords. This requires a few extra steps, as explained below. Thanks to Setting up public key authentication over SSH for this part of the post.

On your client machine, you need to generate a new public and private key pair using RSA as encryption type and key strength as 4096 bits. You will be asked for a password. You can leave it blank but I recommend you put something in there. The reason is that if your private key gets into the wrong hands, they still need a password to be able to use it.
ssh-keygen -t rsa -b 4096

Now that a public/private key pair has been generated, you can use the keys. You first need to copy the public key from your client machine to your ssh server machine. You copy it to the user’s home directory on the server in the .ssh directory. For example, on the server you would need to copy it to /home/codeghar/.ssh/ directory. If it doesn’t exist, create it.
scp /home/codeghar/.ssh/id_rsa.pub codeghar@example.com:/home/codeghar/.ssh/myclient.pub

On the remote server, do the following so that the public key is appended to the authorized keys file
cat /home/codeghar/.ssh/myclient.pub >> /home/codeghar/.ssh/authorized_keys

Now you can remove the original file because it’s no longer needed.
rm /home/codeghar/.ssh/myclient.pub

This has to be done for each client and also for each allowed user on the server. For example, if user codeghar uses two client machines, he/she needs to generate these pairs on each machine and then copy over the public key to the server. And if the server has two allowed users, both need to have these public keys in their own authorized keys files for them to be able to login.

You have copied over the public key but you still need to tell ssh to only use this key for authentication. Disable password authentication and enable public key authentication in /etc/ssh/sshd_config file by making sure the following lines exist in it.
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no

Activate Your Changes

You are now ready to activate these changes. Be aware that if you activate these changes and you made a mistake somewhere, you may lose all access. For this reason, establish an ssh connection first for the ‘just in case’ scenario and do not logout unless you are satisfied all things are working as they should.

To activate the changes, run the following command:
sudo /etc/init.d/ssh restart

Test the changes you have made so far by trying to login using a user who is not in the mysshgroup group, by logging in as root, and by using password authentication. All should work well.

If you are still asked for a password, or you get a Permission denied (publickey) error, then the ssh daemon/process thinks the settings of .ssh directory and/or the authorized_keys file on the server are insecure. To remedy the situation, you should change the permissions as below (hat tip: Public and Private Keys):

chmod 700 /home/codeghar/.ssh
chmod 600 /home/codeghar/.ssh/authorized_keys

Throttle ssh Connections

Although you have taken the aforementioned steps to make your server more secure, attackers are still going to attempt. With the above changes you should be secure but I prefer to add another layer: iptables firewalling. The idea is to restrict three attempts per minute for a new ssh connection from a single IP. This way you still have the ability to try three times a minute in case you provide wrong credentials. But it also means an attacker is restricted to three attempts per minute per IP. It doesn’t completely eliminate brute force attacks but it ought to slow these down.

You need the following three rules. Thanks to Using iptables to rate-limit incoming connections for helping with this section.
sudo iptables --append INPUT --protocol tcp --match tcp --destination-port 22 --in-interface eth0 --match state --state NEW --match recent --set
sudo iptables --append INPUT --protocol tcp --match tcp --destination-port 22 --in-interface eth0 --match state --state NEW --match recent --update --seconds 60 --hitcount 4 -j DROP
sudo iptables --append INPUT --protocol tcp --match tcp --destination-port 22 --jump ACCEPT

The first rule adds the IP of the client machine which initiates a new ssh connection. The second rule checks if this IP has attempted four or more connections in the past 60 seconds. If it has, this attempt is dropped. If it hasn’t, then it is allowed to ssh using the third rule. This way you get to try three times per minute but the fourth and subsequent attempts are blocked for a whole minute.

Other useful resources are: SSH Dictionary Attack Prevention with iptables; ssh – authorized_keys HOWTO; Throttling SSH attacks with pf; Port Knocking – A Cure for the Common SSH Login Attack;

Follow

Get every new post delivered to your Inbox.

Join 31 other followers