Lightweight Ubuntu: LXDE Desktop from Scratch

The overall Linux performance depends on the amount of system resources your desktop environment is using. Lightweight desktop environments such as LXDE consume less resources, and are ideal for older computers that can’t keep up with heavier Linux desktop environments.

This article describes how to build an Ubuntu-based LXDE system piece by piece. It is a longer process but the resulting system is as small and light as it possibly gets. I start by installing a regular Ubuntu 14.10 server system and add desktop functionality on top of it in small steps.

Server Install

The installation of Ubuntu Server is actually very straight forward. You first need to download the ISO image from the Ubuntu Website and burn it to a CD. You can also copy the ISO image to a USB flash drive.

Boot the computer from CD or USB stick and go trough the install menus one by one.

Ubuntu Server 14.10 install

Lightweight Debian: LXDE Desktop From Scratch Part 2

In part 1 of this article series I’ve described a minimal Debian installation using network install image. I started with a regular server, added the desktop environment, and installed some more common desktop applications. In this article I will continue with several enhancements to the previous setup. Most of the information in these articles applies to other desktop environments as well.

A Memory Comparison of Light Linux Desktops – Part 3

Linux kernel manages all RAM memory in your computer. Unused memory goes into a special buffering pool, where the kernel caches all recently used data. If a process attempts to read a file and the kernel already has the file cached, reading it is as fast as reading RAM.

Filesystem-heavy task, such as compiling source code, processing video files, etc. benefit from as much free memory as possible in buffering pool. It is not uncommon today to see users with powerful systems running tiling window managers in only a few megabytes of memory. Also, with the personal computer market in decline, people tend to keep their computers longer.

In this article I continue the measurements started in part 1 and part 2 of this series.

I use free command to measure memory. It basically prints out values provided by the kernel. Of interest to us is the number on -/+ buffers/cache line, 121MB in the example below:

Measuring desktop memory

Debian Virtualization: Back to the Basics, part 3

The traditional Linux security model starts with file permissions. The model lets the kernel decide whether or not a process may access a resource based on permissions set as part of the filesystem. The coarse-grained granularity of this model often causes Linux processes to have too many rights. If more granularity is needed, one has to resort to adding security related code into the program source.

This series of articles is about Linux namespaces, a lightweight virtualization technology implemented in Linux kernel. In part 1 I’ve talked about building chroot jails using mount namespace, and in part 2 I’ve looked into isolating processes using PID namespace. The next step is to isolate the TCP/IP networking stack using network namespaces.

Security at this level is always reactive. Assuming the bad guy breaks into your server, he will realize he doesn’t have root privileges (classic Unix privilege separation implemented in server software), he runs on top of a fake filesystem (chroot), and he cannot get outside on the network. The later is usually done by placing the computer in a Demilitarized Zone (DMZ) behind a firewall.

The same effect can be achieved on the cheap using Linux namespaces. For this, I place the server in a container (vm1) running its own network segment (10.10.20.0/24). The container is connected to the host through a Linux bridge interface (br0). On the host I configure iptables firewall, isolating the server and effectively limiting the potential damage that could be inflicted on the larger network. The final setup looks like this:

Network setup

Debian Virtualization: Back to the Basics, part 2

Linux ptrace() system call provides a means by which one process may observe and control the execution of another process. It is primarily used to implement breakpoint debugging with gdb and system call tracing with strace. In this article I will look at the security implications of ptrace, and how to overcome them using Linux PID namespaces.

Public enemy numero uno

This is an experiment every Linux enthusiast should try. Start an ssh connection in a terminal and stop when you are just about to enter the password:

Starting an ssh session

Open another terminal, find the pid of your ssh session (ps ax | grep ssh) and start strace on it (strace -p 3660). Then, go back to your ssh terminal, type in your password, and watch it flying across strace terminal:

ptrace usage example

Debian Virtualization: Back to the Basics

Namespace isolation is the simplest virtualization technology available in Linux kernel. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table. This feature is mostly popularized and promoted by utilities such as LXC (Linux Containers), Docker and virtenv.

Three syscalls are used to create Linux namespaces, unshare(), clone() and setns(). In this article I will take a look at unshare() and show how to use it directly in your scripts and programs without going through LXC or any other higher level virtualization tool.

I’ll start by investigating unshare command available in util-linux package, and from there I’ll move to the system call. In the end I’ll build a small C program that isolates a web browser such as Mozilla Firefox into a kernel namespace.

Four Lightweight Desktops for openSUSE 13.1

It might not get the attention Fedora and Ubuntu do, but its parent is still one of the major enterprise Linux distributions. Released on schedule as always, openSUSE is considered by many to be the best KDE distribution, constantly contributing directly to upstream KDE project. A number of other desktops are also supported, I will take a look at some of them in this article.

I’ve installed openSUSE 13.1 using openSUSE Network Installation CD (netinstall). I brought in the desktop environments one by one, reboot the computer, log in, and measure the startup memory for each one of them in a terminal. I left the desktops as they were installed by default, without any modifications.

Measuring memory is easy, Linux kernel keeps track of it all the time. Kernel data is accessed by free command, and printed on the screen. Of interest to us is the value on -/+ buffers/cache line, 121MB in the example below:

Measuring desktop memory

Fedora Memory Comparison

Adam Williamson from happyassasin.net has a nice article titled Some comparisons between Fedora 13, 15, 17, 19 and 20. Adam works for Red Hat as Fedora QA Community Manager, meaning he knows what he’s taking about:

We can see that the memory used when you simply boot to a console and log in has changed very little all the way back to Fedora 13, released 2010-05-25. We’re doing a fairly good job of keeping our base system from bloating excessively. 19 and 20 are both 30MB worse than 17, but then, 17 was 25MB better than 15.

The same certainly doesn’t hold true for the graphical desktop, though. Just sitting at a mostly-idle desktop with a terminal open, our memory usage has gone from 275MB under the ancien GNOME 2 regime to 300MB with GNOME 3′s ‘fallback mode’ (which was more or less GNOME 2), then rocketed to nearly 400MB, 535MB, and nearly 700MB in subsequent releases. I haven’t yet looked in detail at the changes, but I did take screenshots of ‘top’ ordered by memory usage for each install.

The measurements are done using free command in a gnome-terminal immediately after bootup. GNOME runs in a virtual machine without hardware acceleration, and it ends up using Mesa llvmpipe driver. These are the graphs based on Adam’s measurements:

Fedora server memory (MB)

Fedora GNOME Desktop memory (MB)

Debian Virtualization: LXC debootstrap filesystem

Virtualization refers to the creation of virtual machines that acts like real computers with an operating system. Software executed on these virtual machines is separated from the underlying hardware resources.

This article discusses LXC, a lightweight virtualization technology built into Linux kernel. The user space LXC tool is distributed with a number of templates that allow the creation of different Linux distro filesystems, usually one template for each major Linux distribution. The problem with these templates is they never work, or they stop working with every new release of LXC tool or of the particular Linux distribution. This is the case with all Linux distributions, and Debian is no exception. Currently, the Debian template is borken under “wheezy”. The relevant Debian bug is here, and history shows that as soon such a bug gets fixed, lxc user space driver changes again and breaks it. It could be worse, in Fedora LXC was broken in Fedora 15 and it was never fixed.

The simple way to handle the problem is to forget all about the template mechanism and roll your own containers. In Debian you can build the container filesystem using the standard debootstrap, or mount read-only the host filesystem, and then use lxc-execute to start a simple bash session inside the container. In this session you can than start all the programs you need to run in the container. It is an application container, very similar to the containers created using the official ssh template distributed with LXC.

The virtual machine I will describe in this article uses a root filesystem build using debootstrap (apt-get install debootstrap). The procedure is simple and it should work on any Debian machine. It will probably work also on any other distro based on Debian, such as Ubuntu, Mint etc.

Linux SNMP MIB Browser

An SNMP MIB browser is an indispensable tool for engineers and system administrators to manage SNMP enabled network devices such as routers, switches, servers and workstations. The information provided by SNMP includes uptime, interface traffic data, routing information, TCP and UDP connection information, installed software, and much more.

In this tutorial, I introduce qtmib, an easy-to-use SNMP browser available for Linux and published under GPLv2 license. The program is build as a front-end for net-snmp tools using QT4 library.

qtmib browser window

Pages: 1 2 3