Home » Computing » Archive by category "Linux" (Page 5)

Installing CentOS Minimal


[This post is now fairly obsolete and has a few problems. I am in the process of re-writing it. It should still lead you to a fully functioning CentOS 6 system, but overlooks some significant parts, so use due diligence and read up on topics as you go along!]

This post is intended as a guide to Linux beginner-enthiasts to the basic setup pitfalls when performing a minimal install of the Community Enterprise OS, and point out some basic command line techniques that every Linux user should know. CentOS minimal, as its name implies, is very minimalistic, and does not ship with a nice graphical interface, but instead drops you in the command line after installation.

Here’s what I’ll cover:

  1. Download and install
  2. Create a user and add to sudoers
  3. Networking
    1. A note on SSH
  4. First basic YUM operations
  5. GUI installation
  6. Apache installation and locations
  7. Opening the Firewall: iptables
  8. rpm, make and ndiswrapper – driver installation

Read more

Installing applications on the GNU/Linux command line

This post answers these questions:

  • How do I install on Ubuntu/Linux Mint/Bodhi/(a Linux based off Debian) on the command line?
  • How do I install on CentOS/Korora/Fuduntu/(a Linux based off Fedora) on the command line?
  • How do I use apt-get/yum?
  • When should I use apt-get update?
  • When should I use yum update?
  • What is the build-essential package for?
  • Why should I install the “Development Tools” package group?
  • I tried installing from source using the ./make command but I get lots of build errors.


There are several ways to install applications on Linux, depending on your distribution, but for the purpose of this particular article, I am going to focus on the Debian family, which use the apt-get utility – this includes the more popular distributions, Ubuntu and Linux Mint – and the Fedora family, which use the yum utility, as do CentOS and Scientific Linux.

One way to install applications is to use the graphical software manager, but I try to not use that. I decided to get more familiar with installing from the command line, for two reasons: a number of programs you’ll come across may require it, and more importantly if the install fails, it’s best to be able to see the full list of messages from the install – this is generally hidden by the automatic installers.

Repositories and package managers

To start off with, package managers are software that download your software from repositories and install them, keeping track of what’s installed and in what version.

In the most simplistic terms, the repositories are online servers that host numerous versions of a vast number of applications, and the package manager is the utility that connects to these repositories, and installs applications, which come in the form of a number of packages. Depending on the Linux distribution, the corresponding repository may systematically make the latest versions of applications available, or only the latest known stable and fully tested version.

For example, Fedora tends to have the most up to date applications; the repository servers are maintained by Red Hat (who make Fedora) who make these latest versions available through their servers.

On the other hand, Debian will rigorously test and approve packages before releasing them to their main Stable repository. This emphasis on stability means that packages available normally are quite old already, unless you opt to subscribe to the “Testing” repository, or even “Sid”, the so-called “unstable” repository.

The Ubuntu family, like many derivative families, tend to be in between these two extremes, releasing fairly recent versions, but not after a certain amount of testing.

Other offshoot distributions may also use another distro’s repository so long as they are compatible. Thus Linux Mint, which is based on Ubuntu, uses Canonical’s repository primarily, whilst also providing their own.

You may think a repository then is hardly more than an App Store for GNU/Linux, but there’s a more technical side to it – these repositories do not only hold applications, but libraries, code packages that other applications can use. Windows users are perhaps more familiar with the “missing DLL” errors, Mac users probably know they need to hunt for other apps to support the app they are trying to run.

Each GNU/Linux package also comes with a list of packages it depends on. The package manager on your computer then figures out what it needs to install first, what versions and in what order, before installing the package you told it to install. It will make sure another program that uses a different version of the package doesn’t mess with your first app; and when you come to uninstalling the package, it will also remove any packages that are no longer necessary in your system.

Package manager applications

Packages can come in different formats depending on distro, and the trio of package type, package installer and package manager identifies the distribution family of any distro.

Ubuntu, Linux Mint, and Knoppix, all popular distros in their own rights, use the DEB packages as prescribed by their parent distribution Debian, installed by the dpkg package installer, nowadays piloted by the APT package management tools.

Mageia, RedHat Enterprise Linux and Yellow Dog Linux are all children of the Fedora family, and thus use RPM packages, the rpm package installer, and the yum package manager (from Yellow Dog itself).

ArchLinux and its derivatives such as Chakra and Manjaro use specially structured .tar.gz files, and the package manager and installer pacman.

Slackware breaks the mold in that it just has .tgz files, and for a long time it did not have a package manager. A number of third party tools arose in the child distros, including slapt-get, netpkg and slackpkg, and finally swaret that features dependency resolution, which the others do not support themselves.

A number of other systems and families exist, but those are the most common. For the rest of this article, I will focus on apt-get and yum – they are the two with which I am the most familiar, and they are used in the two largest and common families.

The command line, and sudo


In the following text, command prompts are indicated by starting with “$>” – so if a command is listed as

$> apt-get update

this means to use the terminal program and run the command “apt-get update

About sudo

You will find most commands in this article start with the word “sudo”.


sudo (pronounced “soo-doo” by some, I say it “soo-doh” like “pseudo”) is a special command, which means “run the following command with root privilege.” Most of the time, you are best not running any commands as root – this is a failsafe to prevent you from doing something silly, like deleting your entire system whilst performing an everyday command. Which, yes, you can end up doing if you’re not careful. sudo tells the machine you really mean it. Before it does anything, it will ask you for your password, and will then check if you are indeed allowed to run admin commands. If you run a second sudo command soon after, it will not ask you again, with a timeout depending on distro.

First time setup

Before you do any installation, the package manager needs to be aware of all the latest versions, and crucially, dependencies. Before a session of installing with APT, you must execute:

$> sudo apt-get update

This will update APT’s package library.


YUM on the other hand updates its repository list every time it is run, so you don’t need to worry about this.

After freshly installing a distro, it is useful to install the development and supporting build tools you are likely to need in the future – for APT this is:

$> sudo apt-get install build-essential

For YUM this is:

$> sudo yum install @development-tools

This will install a number of other packages that are generally required to build applications from source, most notably the GNU C and C++ compiler suites and libraries, as well as python build tools and perl tools.

Makefiles, installer scripts which usually ship with source code downloaded from the web, depend on these tools being installed on your system, and trying to run a Makefile without them will generate a slew of errors.


The basic APT command for installing a package is

$> sudo apt-get install <package>

Under YUM, there is a difference between a single package with dependencies, and a named group of packages. For an individual package, the following is used:

$> sudo yum install <package>

For package groups, the following two lines are equivalent:

$> sudo yum install @group-package
$> sudo yum groupinstall “Group Package”

See the examples from the previous section for comparison.

You will be asked whether to proceed, after having been given a summary of what packages will be updated and how much extra space will eventually be taken on your system.


Building from source code

If you download the source code for a package from off the web, you’ll normally be given a README and a ‘Makefile’ file. The Makefile contains instructions for building in various modes. Most often, simply switching to the directory and running the following will work (but please, do always read the README file first – do it the courtesy of its name!)

$> sudo make
$> sudo make install

This also holds true if you’re given an installer file – for example, the VirtualBox Guest Additions has a script for installing the VirtualBox add-ons, which requires the build-essential package to be installed. It doesn’t tell you so though – instead, it advises that it couldn’t find gcc (the C compiler).

Updating your OS

Depending on which distro you are using, you may need to upgrade your system frequently, occasionally, or not at all.

Debian, RedHat and CentOS tend to make any individual release supported for a long time, meaning that they will continue to actively develop and push security fixes and bugfixes for that release. You probably will only truly need to reinstall the system once every 7 years or so, a trait which makes these distros suitable for servers.

Fedora on the other hand likes to only have the latest software on hand, and regularly releases new distro versions every six months. Each is supported only for a year after the following version is released, which means under the current six-month cycle, any individual release is only supported for 18 months after its initial release. You’ll need to re-install the system again after that time. In this situation, it is a good idea to isolate your /home directory from the system. For people who tend to upgrade their machines regularly, or tend to experiment a lot on secondary systems (and break these in the process), this is not so much of an issue.

Linux Mint advises that you should be able to keep your current installation as long as you wish: from the Linux Mint upgrade notes: “Unless you need to, or unless you really want to, there’s no reason for you to upgrade.” – check the Linux Mint Community pages for more info. I personally disagree with this stance, as it seems to imply that you can choose to stay on a release that is no longer supported, from a security standpoint. As stated in the linked page, any one release only receives updates for 18 months until it is abandoned. Unless you are yourself well versed in security maintenance (and even then), it is probably not a good idea to stay on a system that is not receiving security updates.

Finally, there is also the Rolling Release model which is adopted by for example the Linux Mint Debian Edition and the ArchLinux distributions, which simply update the current installation as and when you run the upgrade function of the package manager.


That’s the end of the tutorial. Have fun installing lots of fun apps – take a look at this list for a start, and happy installing!