We're moving into the lower levels of the Linux operating system, leaving behind the realm of user interaction, GUIs, command lines and relative simplicity.
The best way of explaining what goes on at this level is to go through the booting process up to the point where you can choose either a graphical session or work with the command line, and the first thing you see when you turn your machine on.
The init process is used by many distributions, including Debian and Fedora, to launch everything your operating system needs to function from the moment it leaves the safety of Grub. It's got a long history – the version used by Linux is often written as sysvinit, which shows its Unix System V heritage.
Everything from Samba to SSH will need to be started at some point, and init does this by trawling through a script for each process in a specific order, which is defined by a number at the beginning of the script's name. Which scripts are executed is dependent on something called the runlevel of your system, and this is different from one distribution to another, and especially between distros based on Fedora and Debian.
GUFW: You don't have to mess around with Iptables manually if you don't want to. There are many GUIs, like GUFW, that make the job much easier to manage
You can see this in action by using the init command to switch runlevels manually. On Debian-based systems, type init 1 for single-user mode, and init 5 for a full graphical environment. Older versions of Fedora, on the other hand, offer a non-networking console login at runlevel 2, network functionality at level 3, and a full blown GUI at level 5, and each process will be run in turn as your system boots. This can create a bottleneck, especially when one process is waiting for network services to be enabled.
Each script needs to wait for the previous to complete before it can run, regardless of how many other system resources are being under-utilised.
If you think the init system seems fairly antiquated, you're not alone. Many people feel the same way, and several distributions are considering a switch from init to an alternative called upstart. Most notably, the distribution that currently sponsors its development, Ubuntu, now uses upstart as its default booting daemon, as does Fedora, and the Debian maintainers have announced their intention to switch for the next release of their distribution.
Upstart's great advantage is that it can run scripts asynchronously. This means that when one is waiting for a network connection to appear, another can be configuring hardware or initiating X. It will even use the same scripts as init, making the boot process quicker and more efficient, which is one of the main reasons why the latest versions of Ubuntu and Fedora boot so quickly in comparison with their older counterparts.
The kernel
We've now covered almost everything, with one large exception, the kernel itself. As we've already discussed, the kernel is responsible for managing and maintaining all system resources. It's at the heart of a running Linux system, and it's what makes Linux, Linux.
The kernel handles the filesystem, manages processes and loads drivers, implements networking, userspaces, memory and storage. And surprisingly, for the normal user, there isn't that much to see.
Other than the elements displayed through the /proc and /sys filesystems, and the various processes that happen to be running in the background, most of these management systems are transparent. But there are some elements that are visible, and the most notable of these is the driver framework used to control your hardware.
Most distributions choose to package drivers as modules rather than as part of the monolithic kernel, and this means they can be loaded and unloaded as and when you need them. Which kernel modules are included and which aren't is dependent on your distribution. But if you've installed the kernel source code, you can usually build your own modules without too much difficulty, or install them through your distribution's package manager.
To see what modules are running type lsmod as a system administrator to list all the modules currently plugged into the kernel. Next to each module you'll see listed any dependencies. Like the software variety, these are a requirement for the module to work correctly.
Modules are kernel-specific, which is why your Nvidia driver might sometimes break if your distribution automatically updates the kernel. Nvidia's GLX module needs to be built against the current version of the kernel, which is what it attempts to do when you run the installer.
Fortunately, you can install more than one version of a module, and each will be automatically detected when you choose a new kernel from the Grub menu. This is because all the various modules are hidden within the /lib/modules directory, which itself should contain further directories named after kernel versions.
You can find which version of the kernel you're running by typing uname -a. Depending on your distribution, you can find many kernel driver modules in the /lib/modules/kernel_name/kernel/drivers directory, and this is sometimes useful if your hardware hasn't been detected properly.
If you know exactly which module your hardware should use, for example, you can load it with the modprobe module name. You may find that your hardware works without any further configuration, but it might also be wise to check your system logs to make sure your hardware is being used as expected.
You can remove modules from memory with the rmmod command, which is useful if Nvidia's driver installer complains that a driver is already running.
Iptables
One of the more unusual modules you've find listed with lsmod is ip_tables. This is part of one of the most powerful aspects to Linux – its online security.
Iptables is the system used by the kernel to implement the Linux firewall. It can govern all packets coming into and out of your system using a complex series of rules. You can change the configuration in real time using the iptables command, but unless you're an expert, this can be difficult to understand, especially when your computer's security is at risk.
This is a reflection of the complexity within the networking stack, rather than Iptables itself, and is a necessary side effect of trying to handle several different layers of network data at the same time. But if you're used to other systems and you want to configure Iptables manually, we'd recommend a GUI application like Firestarter, or Ubuntu's ufw, which was developed specifically to make Iptables easier to use.
When it's installed, you can quickly enable the firewall by typing ufw enable as root, for instance. You can allow or block specific ports with the ufw allow and ufw deny commands, or substitute the port with the name of the service you want to block.
You can find a list of service names for the system in the /etc/services file, and if you're really stuck, you can install an even more user-friendly front-end to Iptables by installing the gufw package.
It's not the end
We've uncovered all the essential aspects of the Linux operating system, and we hope you've now got a much better understanding of how it all hangs together. One of the best things about Linux is that you're free to experiment and change things freely. This is one of the best ways of learning about the system and what it's capable of – as long as you don't try it in a production environment!
Try a virtual machine running your favourite distribution instead, and if you need any help or clarification, try the LXF Forums at www.linuxformat.co.uk/forums.
