Tutorial: Boot Linux Over A Network

Configure your Linux installation, or get a broken system up and running without the need for optical discs and other hardware.

Posted May 18th, 2009 - 3 comments - Share This

You might think that booting a PC off another machine on the same network is the stuff of 1970s labs and thin-client computing. But there are many reasons why the technique is just as useful today as it was then, even with just two machines.

And don’t forget, if you’re a die hard Linux fan, check out other top tutorials – Build your own distro; Build a cluster computer and Build a portable web browser!

For starters, there are now many computers without optical drives, like netbook PCs or home media centres. The only way to upgrade or install an operating system on these devices, short of removing the hard drive, is to either install from a USB stick or use the network boot method. And if, for whatever reason, your system can't boot from a USB device then you only have one option left. Aside from those cases, network booting is also a technique that can help fix broken installations when hardware refuses to work, or distribute an upgrade across a network of machines without needing you to manually slot a disc in each drive.

The ability of your machine to boot off another network device is determined by what's termed the Preboot Execution Environment (PXE). This is a capability of your system BIOS that enables your machine to grab a network address and look for bootable code without first checking local storage, or for available bootable devices. If there are no such drives on your system, you might notice PXE in operation as it searches the local network for a bootable server candidate. It's this candidate that we're going to install, configure and provide.

Install a DNS Server

When a PXE-enabled machine is first turned on, it will attempt to initialise the network interface and connect to a gateway to get on the network. To do this, it's doing to need an IP address and the ability to find a server. The IP address allocation is handled by DHCP. This doesn't normally require configuration, as our switch or router works out DHCP automatically, but for PXE network booting you will need to install and configure your own DHCP server. Fortunately, there's an excellent Linux tool that also includes DNS capabilities, which makes it an ideal solution for network booting. A DNS server is required here because we need to add our own boot server as a preconfigured network address so that the PXE boot code knows where it should look to find further instructions.

From a standard Ubuntu installation, you need to add two packages - 'dnsmasq' and 'dnsmasq-base' - using the Synaptic package manager. The dnsmasq server is designed specifically for small networks such as those found at home, but it can scale to serve around 1,000 clients. It has built-in support for network booting devices and it is simple to configure, unlike most other DNS servers.

DHCP Configuration

The configuration of dnsmasq is accomplished by editing the '/etc/dnsmasq.conf' file after installing the two packages. You'll need to open this with a text editor using system administrator privileges - to do this we suggest typing either 'sudo nano /etc/dnsmasq.conf' or 'sudo gedit' into the command line. Next add these four lines to the bottom of the file, changing the IP addresses to suit your network's configuration:

dhcp-range=192.168.198.130, 92.168.198.140,12h

dhcp-boot=pxelinux.0,192.168. 198.128

dhcp-option=3,192.168.198.2

dhcp-option=6,192.168.198.2

The first line of this text holds the range of addresses that you want to be served by the DHCP server. In this case, our network is 192.168.198.0 and we've assigned DHCP addresses between 130 and 140 for dynamically allocating clients. The second line requires you to add the IP address of the machine you're using to be the server; normally this machine is the one you're installing the server onto. This entry tells the client to look for 'pxelinux.0' as part of the PXE boot routine in the direction of your IP address. Ours is 192.168.198.128. The last two lines take the IP address of your gateway, which is 192.168.198.2 in this example. If you're having trouble finding the correct numbers, try typing 'ifconfig eth0 | grep inet' on the command line. This will list your server's current network address. Once you have it, you can enter this on the second line of our configuration. For the gateway's address, type 'route'. This will display the IP addresses taken by packets as they traverse your network and the 'default' listing will show an IP address for your gateway, which you can use on the last two lines of the dnsmasq configuration file.

With the configuration complete, you can now kick the dnsmasq server into life by using the following console command: 'sudo /etc/init.d/dnsmasq restart'.

Install the TFTP Server

Since the client machine has been given an IP address and informed that it needs to grab 'pxelinux', the next step is to provide those files using a Trivial File Transfer Protocol (TFTP) server, which is a simple version of the more commonly used FTP protocol. Its simplicity means that it's perfect for low memory situations - exactly what PXE code hiding on a diminutive BIOS needs. The most suitable Linux TFTP server is called 'aTFTP' and this can be installed by searching for the package named 'atftp' in Synaptic. After you've installed it, you'll need to find and edit the configuration file, located in '/etc/default/atftpd.conf'.

You just need to change the 'USE_INETD=true' option on the first line of the configuration file to 'false' and make sure that the last parameter in the 'OPTIONS' string points to a usable location on your file system. It's going to store the boot files needed by PXE and by default this points to '/var/lib/tftpboot' - a directory that currently doesn't exist. Other distributions use '/tftpboot' as a standard location, but it doesn't really matter which one you choose as long as you use the same location to store the PXE boot files, which we'll move on to create in the next step.

If there's a firewall between your PXE booting client and the server running TFTP, you need to make sure that UDP port 69 is open and accessible to the client. The Uncomplicated Firewall that's enabled in most Ubuntu installations can be disabled by typing in the command 'sudo ufw disable', but only execute this if your machine has another firewall to protect itself and you're absolutely sure that there's not going to be any added security risk to your system. With the configuration complete, you can start the aTFTP server by typing 'sudo/etc/init.d/atftpd restart'.

Create the boot files

Now that we've got both the servers that PXE requires to negotiate a connection and find the files it needs to boot, the next task to accomplish is to make those files available. There are many different sources and methods for creating and adding these files, and which one you choose is entirely dependent on what you want your network-booted operating system to do. You could boot to a completely functional Live CD system, for example, but we're opting for a networked Ubuntu installation instead. Earlier versions of Ubuntu included the PXE boot files on the distribution CD, but space restrictions have meant that these files were offloaded into an online repository. Visit www.tinyurl.com/5waq63 to get hold of this file and then place it in the directory that aTFTP is expecting to find it in, which is '/var/lib/tftpboot' by default.

The netboot file comes as a 'tar.gz' archive. This can be opened by a file manager, but for best results, just type 'tar xvf netboot.tar.gz' into the command line. All the files and directories will then be un-archived into the current directory, as required. These files will include the 'pxelinux.0' file that we pointed the dnsmasq configuration file towards earlier. A PXE boot menu is configured through the 'pxelinux.cfg' directory, which contains a file that should look familiar if you've ever edited the Grub bootloader. It includes an entry for each boot menu - which contains the location of the boot kernel and RAM disk - as well as where to find the root file system. It's this file that you'll need to edit if you add your own PXE installations. The 'ubuntu-installer' directory is a cut-down version of the Ubuntu install CD, restricting itself to text and online repositories in order to keep its use of space and network bandwidth to a minimum.

Boot the client

You're now at the stage of the process where a network boot should work, but before you try everything you've done here out, it's worth checking the server to make sure everything is set-up correctly first. Specifically, check that both the dnsmasq and atftp servers are running and that they're awaiting a connection. This can be done using the 'netstat -nulp' command followed by '| grep', which is used to filter the output to the specific server name you require information on. If you were to type in 'netstat -nulp | grep dnsmasq', for instance, netstat would output the three lines that report on the current status of the dnsmasq server - if it's working, that is. If not, restart the server manually, follwing the same proceedure that we used in step two. Repeat the same netstat process for checking the status of the atftp server. If you find that restarting either service still doesn't produce any usable netstat output, it's likely that there's a syntax error in that server's configuration file. You should be able to learn more information about the problem from the system logs: try looking in '/var/log/messages'.

Once you're happy that both services are running, and that any firewall you've got installed isn't getting in the way of the process, it's time to start your client PXE booting machine. If there's no other bootable device on this machine then the PXE booting should automatically kick in. If not, you'll need to enter the BIOS and manually and change the boot order on that machine, pushing the network booting capability to the top of the priority list. The majority of BIOS configuration menus can be entered by pressing either [F2] or [Delete] when the BIOS first appears on your screen. Failing that, some BIOSes will provide a network booting hotkey (usually [F12]) or a manual boot selection menu (usually [F8]). When the network booting attempt is successful, you will see your network device first try to grab an IP address from your new DHCP server before taking the boot file we've placed on the aTFTP server. All of this should happen very quickly. You'll then be presented with the PXE boot menu created by our boot file configuration and from that point onward, installing Ubuntu across the network is a fairly simple matter of following the on-screen prompts until completion.

What no PXE-Enabled BIOS?

If you haven't got a PXE-enabled BIOS then you won't be able to boot off a network device without some form of boot media, which brings you firmly into the world of thin-client computing. Unlike booting from PXE, a thin client needs a rudimentary operating system running off some form of local storage device. The most popular trick is to use a low-capacity USB stick with a very minimal Linux installation to create a simple Linux environment that then boots from a fatter server located on the network. In the past, building a workable Linux distribution onto a USB stick has been problematic, but the latest release of Fedora includes a utility that will create a bootable USB stick with just a couple of clicks on a GUI. There's even an open-source project called UNetBootin that you can use from almost any operating system.

The features you should include on the USB installation are dependent on how you want to use your client. You may simply want to access a remote desktop on a VNC server, for example. For this purpose, all you'll need is the TightVNC client package and a working X Windows configuration. A more ambitious thin client would quickly mount an NFS shared drive to act as the home directory and application server for the client. This has the advantage of letting the hardware run at its native speed, rather than being limited by the bottleneck of a remote desktop connection. Coaxing a workable configuration from NFS can be tricky, though.

Boot into a Live CD

Using PXE network booting to start an Ubuntu installation without any installation media on the client machine is a convenient example of network booting, because the distribution supplies the netboot package. The netboot archive includes all of the binaries and configuration files necessary for the PXE client to boot and that setup isn't trivial to build manually. However, the netboot package is a great place to start if you want to extend this configuration and boot an Ubuntu Live CD. You can even boot a different Linux distribution entirely, although you'll need to stick to a Live CD since these are the only distributions capable of initialising hardware on-the-fly rather than through an installation.

The first step is to download an ISO of the desktop distribution. You then need to copy the contents to a directory on your Linux server and share the contents of that directory using the Network File System. This can be installed through Synaptic, but you'll need to edit the '/etc/exports' file to add the ISO directory you created and copied files to. After this, edit the netboot configuration, copying 'vmlinuz' and 'initrd.gz' from the 'casper' directory to somewhere within the path of the aTFTP server. We used '/var/lib/tftpboot/hardy'. Finally, edit the netboot configuration file and add the following, changing the paths and IP address.

LABEL Hardy-Heron kernel hardy/vmlinuz append boot=casper

netboot=nfs

nfsroot=192.168.198.128:/path/to/nfs/share initrd=hardy/initrd.gz

Read more »

Run Linux Applications on Windows

Install the Windows port of KDE and get instant native compatibility with all kinds of great open source Linux software.

Posted June 4th, 2009

One of the best things about open-source software development is that anyone with the inclination and a modicum of talent can have a go. You don’t need expensive software, you don’t need developer accreditation and you don’t need planning meetings. With Linux, coding is as easy as installing a development environment and firing up a text editor – as long as you can program, of course. Linux itself is the result of this anarchy, but there are thousands of other apps that have grown from similar origins. While some can’t compete with the quality and stability of proprietary commercial offerings, there are many that can – and as a result, there’s considerable demand for the best open-source software on non-open platforms. Audacity, GIMP, Inkscape, Pidgin, Scribus, Ardour and numerous other applications have all been through the porting process to bring some of their goodness to Windows. But earlier this year, something far more ambitious happened: a large chunk of the KDE desktop was ported across.

KDE is one of the two most frequently used Linux desktop environments, and it includes desktop widgets, an instant messenger client, multipaned file and web browsing, the Amarok music player and the Digikam photo manager – some of the best that open source has to offer. KDE has accumulated a huge userbase, and the last 18 months have seen it move from version 3.5 to version 4.2. The toolkit that has always provided most of the functionality behind KDE is called Qt, a commercial suite of libraries and APIs released using both open-source and proprietary licences. Fourth-generation KDE applications use fourth-generation Qt, and part of that upgrade involves a commitment to cross-platform compatibility. Despite the fact that Qt has been mostly cross-platform for some time, it still takes a considerable amount of effort to create portable KDE applications out of the older code base. That’s why the move to true portability has taken so long, and why the February release of KDE is so significant.

Getting started

After obtaining the KDE installer and launching it, you have the option of either installing from online package repositories or using packages within a local directory. You can also download the packages without installing them, which is handy if you’re going to install KDE on several machines. The download location for these files is one of the options in the configuration panel. After clicking on ‘Next’, you’ll be asked for KDE’s installation directory. This can safely be left at the ‘Program Files\KDE’ default. The next page asks whether you want an End User installation or a Package Manager installation. The first option is the most straightforward, as it’s for people who just want to use the KDE desktop; you should only select Package Manager if you’re intending to build your own packages for the Windows project. The installer can also create a GCC-based tool chain for compiling your own software; you can select between the two supported compiler modes in the section in the lower half of the window. You should only attempt this if you’re a competent C++ programmer and understand something of the KDE/Qt APIs.

For the End User installation, select a download path (where the packages will be temporarily stored on your local disk). Skip over the Internet Settings page unless there’s something unusual about your connection. You now need to select a download server as close to your geographical location as possible. Clicking on ‘Next’ will grab the package list from that server. If successful, you’ll see a list of KDE packages you can install. We recommend selecting either ‘Stable latest’ or ‘Stable 4.2.1’, the current package at the time of writing.

Installing KDE

Clicking ‘Next’ should now fill the window with dozens of package names. These are the various components of the KDE desktop. The easiest installation is accomplished by simply clicking on the ‘Select all’ box. Despite its name, this option won’t install everything. For example, it doesn’t include non-English spelling and localisation packages, so if you need support for another language, you’ll need to add both the spelling and languages packages manually. Click ‘Next’ a couple more times and the download process will commence. The time this takes is obviously dependent on your internet connection. If you’ve selected a complete install, there will be around 130 files, which weigh in at about 270MB in total. After the download has completed, each package will be installed automatically onto your system before a post-processing script configures the KDE environmental variables and adds all the packages to your Window Start menu. That’s where you should find the fresh applications of your new KDE desktop after the installation has completed.

If you’ve not used KDE before, it’s worth spending a bit of time learning about a few things that it does differently. An excellent Help file is included in the installation, although it’s a little dated for the current release. But before diving into the menagerie of KDE application proper, it makes sense to configure the KDE GUI to improve its look on Windows. There’s a slight problem in the translation between KDE’s native widgets and those used by Windows, for example, and the default font also looks a little clunky when compared with other Windows apps. Fortunately, both can be changed quite easily.

Configuring KDE

To configure KDE, we need to manually edit a text file. We recommend launching the KDE text editor, Kate, which can be found in your KDE installation’s Utilities menu. Kate is an excellent text editor, and one of KDE’s best-kept secrets. It can highlight and fold code in 24 formats, save sessions and load bookmarks, split the main view into several panels and even complete certain commands automatically. It almost seems a shame that all we’re going to use it for is to edit a configuration file.

Finding that file is a bit of a challenge. Click on Kate’s ‘Open’ button to display KDE’s file requester. You now need to find the Documents and Settings folder on your Windows system, followed by your username and the Application Data directory it contains. From there, click on ‘.kde’ (the dot indicates that it’s hidden on a Linux system) and click on ‘share’, ‘config’ and finally ‘kdeglobals’ to open the file we need. It should be almost empty. We need to add a ‘[General]’ section and populate that with our new options for the widgets and font replacement. You can do this by adding the following lines:

[General]
widgetStyle=oxygen
font=Tahoma
menuFont=Tahoma

Unfortunately, the graphical application that performs this task on the Linux desktop hasn’t made it to Windows yet, but once it does, this step will be even easier. Any subsequent KDE applications you now launch will adopt these amended settings, and they will look and feel much better as a result.

Using Konqueror

The most powerful and unassuming application in the KDE canon is Konqueror. Konqueror is primarily a file manager, although it can be used for many other things – which is why it’s tucked away within KDE’s Internet Applications folder. As a file manager, it’s more powerful than Windows’ Explorer. You can split the main view as many times as you like, for instance. Right-click on the lower window border and select ‘Split View Left/Right’ to create a left and right panel. Both panels are independent, so you can drag files from one location on the left to another on the right, just as you could with file managers of old. You can also create a vertical split and display as many panels as you need. Files can be shown as either an icons-only or detailed list view, not to mention a columns mode reminiscent of Apple’s Finder.

Konqueror isn’t restricted to just files, either. Type ‘gg:news’ into the location bar and Konqueror will search Google for the term ‘news’, displaying the resulting web page in the current view. Web pages are rendered using KHTML, which is the forerunner of Apple’s WebKit. Other terms include ‘ggi:’ for Google Images, ‘wp:’ for Wikipedia and ‘dict:’ for the Merriam-Webster online dictionary, You can enable many more and add your own through Konqueror’s Configuration window, which you can open from the Settings menu.

If Konqueror feels a little too expansive for your liking, try KDE’s new file manager, Dolphin. It’s like a streamlined version of Konqueror, and it can be found in the System menu. You can split the main window only once, but you have the same three modes for file navigation as well as an added ‘breadcrumb’ navigation panel.

Highlight applications

There are plenty of other fantastic applications that are part of the KDE Windows suite. Top of the list has to be Amarok, a music player that’s completely intertwined with the internet. It grabs music and trend data as you listen as well as providing access to several online music stores. The GUI is easily extendible simply by adding and removing widgets from the central information panel.

Another KDE application that we rate very highly is the Kopete instant messenger client. Unlike other multi-protocol IM clients such as Pidgin or Trillian, Kopete can group protocols alongside a single contact. If your contact uses ICQ, Live and Google Talk, for example, this contact only needs a single entry in Kopete rather than the three required by most IM clients, making adding friends and family far less hassle.

Digikam is a wonderful photo and album manager, and it can make short work out of collections of thousands of images. You can add comments, crop, organise and export your photos. A suite of plug-ins let you process your images, and the whole application is quick and easy to use. And if you’re looking for a free image editor, Krita is an excellent example. In many ways it’s more capable than GIMP, especially for drawing. Krita is full of effects, and uses layers in the same way that Adobe Photoshop does.

Finally, there are dozens of education applications and games available, many of which can keep children entertained for hours. In particular, look out for KStars, Kalzium, Marble and Kolf.

Read more »

Playing Games In Linux

Not everything in open source is serious and technical. Find out how to put some games worth playing on your Linux desktop

Posted September 30th, 2009 - 3 comments - Share This

There’s no getting around it: Linux isn’t and probably never will be the first choice of operating system for hardcore gamers. You won’t be able to run any of the latest releases when they come out, and you’ll get much better performance and full DirectX 10 support by sticking with Windows Vista. Sorry.

However, if your gaming needs aren’t quite on the cutting-edge, Linux can be an alternative. It’s a choice that offers many advantages. There are no viruses, no wayward processes chugging away in the background and no spyware, trojans or worms. What’s more, you have complete control over every aspect of your system.

Beyond Tux Racer

With only a few notable exceptions, such as the amazing World Of Goo, there are very few native Linux conversions of recent games. This leaves you with two possible avenues. You can either dual-boot Linux with your Windows installation, giving you 100 per cent Windows compatibility and a Linux desktop, or you can run those Windows games under Linux using WINE. This isn’t an emulator – it’s a wrapper that offers a byte-for-byte translation of what various DirectX and Windows libraries do.

But WINE can be a tricky beast to tame. To get the best out of it, you’ll need to use the infamous Linux command line, a process that will immediately dispel any belief that Linux has left its geeky credentials behind. The good news is that someone’s already done the hard work for you. Crossover Games is a commercial project, which might rankle with hardcore open-source fanboys, but it provides WINE in a simple desktop application that offers one-click access to a surprising number of releases. The money goes to boosting WINE itself, and the cash makes it possible for the system to be updated on a frequent basis.

Crossing over

The tool supports many games, including World of Warcraft, Team Fortress 2 and a host of others. You’ll find a full list right here. Compatibility is graded by gold, silver and bronze awards, and if a game wins any of these, you should be able to play it through without too much difficulty. In our experience, though, performance is usually a little below the equivalent XP speed. Using the Half Life: Lost Coast benchmark as an example, the Linux version (with the same settings) ran around 20 per cent slower, although that didn’t make much difference considering the age of the game.

Even if a title isn’t in the database, it doesn’t mean that you definitely won’t be able to run it. WINE – and hence Crossover Games – will attempt to run any Windows ‘.exe’ file you throw at it. If you like games from an earlier point in the decade, for instance, there’s a good chance that these will run, even without any mention of their compatibility in the database. But you might also have some luck with newer games.

We were able to get Oblivion and Stalker to run by clicking on the ‘.exe’ file from our shared Windows partition, although we couldn’t perform the same trick with Bioshock, presumably because of the copy protection. We were also able to successfully run Valve’s Steam service in the same way, installing it onto a mounted Windows partition. Steam even found the installed games list from our Windows installation, which saved us both the space and effort of downloading and setting them up twice.

Steam is one of the best reasons for using Crossover. Thanks to its civilised anti-piracy mechanism and the download model, plenty of games and demos in its roster will run. From the Crossover application window you can download, install and run the latest Steam client, which will in turn download your games to the Linux desktop. And if they don’t work, you can always revert to Windows.

Our biggest problem came when using a dual-monitor configuration in Linux, as most games can only detect this as a single massive resolution through Crossover. Fortunately, there are two solutions. Either use the game’s Properties field to set a screen resolution or Windowed mode, or force a virtual resolution in the Crossover Games configuration panel. In our experience, Linux is much better at running a game within a window alongside your normal desktop applications, which can be great if you like to run more than one Eve account at the same time.

Hard choices

Unfortunately, software is only part of the equation. Good games performance is equally as reliant on solid Linux driver compatibility, with the biggest sticking point being your choice of PC graphics card. Currently, there’s really only one option, and that’s something from the Nvidia range of cards. ATI cards can be made to work, but they’ll leave you reformatting your hard drive and begging Steve Ballmer for forgiveness.

Linux is open source, but neither Nvidia nor ATI provide open drivers for their hardware. Ubuntu will still detect the hardware, but you’ll need to head online to acquire the drivers. Luckily, audio is another story, and will normally work from the first boot. When it comes to controllers, there’s no easy way to know if things will work. You’ll find that many Logitech joysticks are compatible, for example, but a steering wheel is unlikely to be functional. There are no custom calibration tools and no button configuration utilities either, and feedback is always hit-and-miss. You might think that you can simply install the Windows drivers and tools through Crossover, but you can’t.

If your joystick doesn’t work and you’re after a quick and cheap solution for arcade titles, console controllers work well with a corresponding USB converter and are probably the best way to proceed if you need something heftier than a keyboard and mouse.

The competition

With Crossover, games are installed into something called a ‘bottle’, which is a term for a separate virtual Windows installation. You can keep bottles completely isolated from one another, so that there’s no conflict with shared libraries or other files. It also means that one bottle can emulate Windows XP, while another could attempt Windows 2000 or Vista. These options are dynamic, and you can change almost anything about each bottle through a properties manager that looks and feels much like the real thing on Windows.

If you’re looking to run Bioshock and Oblivion, there’s a competitor to Crossover that will run both on Linux without problems. Transgaming’s Cedega is a private and purely commercial fork of the WINE project. It doesn’t release any of its modifications back to WINE, and it uses a subscription model to keep its customers up to date. If your subscription ends, you’ll still be able to use the software, but you won’t benefit from any updates. While this closed model goes against the open Linux philosophy, it does offer the Transgaming developers certain advantages, such as licensing DRM systems so that more paranoid publishers’ games can be installed and run on Linux systems.

DirectX 10 and beyond

This March, the CEO of the company behind Crossover – Jeremy White – laid out a roadmap for future development. He mentioned that his developers had spent the last year working hard on under-the-hood improvements such as .NET support, Gdiplus and DirectX. As a result of this hard work, DirectX 9 compatibility is looking good in both Crossover Games and WINE. But White’s plans for the next release include the far more ambitious aim of support for DirectX 10, and if development goes well, there may be a compatible version of Crossover Games released by the end of the year. If Codeweavers can achieve this magic trick, there will be a good chance that WINE can be ported back to Windows, bringing DirectX 10 compatibility to older versions of Windows such as XP and 2000 – an irony that won’t be lost on Linux users.

While it’s obvious that Linux is never going to be a hardcore gaming platform, it’s far from a barren wasteland. Technology such as WINE and Crossover presents enough potential to satisfy most persistent gaming urges, and over the course of the next 12 months, the situation is only likely to improve for Linux games. There’s also a world of independent, free and open-source gaming to delve into, and commercial small-scale games such as the aforementioned World Of Goo have been very successful.

As with most things to do with Linux, getting things set up and running properly can be something of an adventure in itself. But to those of us with a passion for the free desktop, that’s half the fun.

Read more »