Scenario: You’ve got some Postfix mail servers running with Postgrey for anti-spam greylisting. They’re all using older versions of Ubuntu such as 10.04 LTS. You’ve decided that it’s time to upgrade them to the next LTS, Ubuntu 12.04.

You do the upgrade and it goes without a hitch. You restart the server, everything looks good, until you start seeing this message in your server’s mail log:

Jan 23 21:17:58 mymailserver postfix/smtpd[7976]: connect from somecompany.com[100.200.300.400]
Jan 23 21:17:59 mymailserver postfix/smtpd[7976]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:17:59 mymailserver postfix/smtpd[7976]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:00 mymailserver postfix/smtpd[7976]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:18:00 mymailserver postfix/smtpd[7976]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:00 mymailserver postfix/smtpd[7976]: NOQUEUE: reject: RCPT from somecompany.com[100.200.300.400]: 451 4.3.5 Server configuration problem; from=<m-1wu7GywwdBK9XOl40cdonjrOvQVbXrSQjrNIttfwaHqBuxTEiR4njb_
n@bounce.somecompany.com> to=<myrecipient@mycompany.com> proto=ESMTP helo=<mail.somecompany.com>
Jan 23 21:18:05 mymailserver postfix/smtpd[7976]: disconnect from somecompany.com[100.200.300.400]
Jan 23 21:18:10 mymailserver postfix/smtpd[7955]: connect from unknown[200.300.400.500]
Jan 23 21:18:11 mymailserver postfix/smtpd[7955]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:18:11 mymailserver postfix/smtpd[7955]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:12 mymailserver postfix/smtpd[7955]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:18:12 mymailserver postfix/smtpd[7955]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:12 mymailserver postfix/smtpd[7955]: NOQUEUE: reject: RCPT from unknown[200.300.400.500]: 451 4.3.5 Server configuration problem; from=<someone@anothercompany.com> to=<myrecipient@mycompany.com> proto=ESMTP helo=<m
ail.anothercompany.com>
Jan 23 21:18:12 mymailserver postfix/smtpd[7955]: disconnect from unknown[200.300.400.500]
Jan 23 21:18:17 mymailserver postfix/smtpd[7976]: connect from mta.ilikecheese.com[300.400.500.600]
Jan 23 21:18:18 mymailserver postfix/smtpd[7976]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:18:18 mymailserver postfix/smtpd[7976]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:19 mymailserver postfix/smtpd[7976]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:18:19 mymailserver postfix/smtpd[7976]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:19 mymailserver postfix/smtpd[7976]: NOQUEUE: reject: RCPT from mta.ilikecheese.com[300.400.500.600]: 451 4.3.5 Server configuration problem; from=<someone@thatcompany.com> to=<myrecipient@mycompany.com> pro
to=ESMTP helo=<MTA.thatcompany.com>
Jan 23 21:18:20 mymailserver postfix/smtpd[7976]: disconnect from mta.thatcompany.com[300.400.500.600]

You almost have a heart attack – every single email is bouncing back and it’s clear that it’s something to do with your upgrade. What went wrong? The errors refer to a configuration issue, but you didn’t change any of the configuration in your upgrade!

Closer inspection reveals that for some reason, Postfix is unable pass messages onto Postgrey which is a local service running on port 10023 by default on Ubuntu systems. If you try telnetting to port 10023 on 127.0.0.1 , you also get a “connection refused” error. So what’s happened?

The answer is that somewhere between Ubuntu 10.04 and Ubuntu 12.04, Postgrey changed the protocol it binds on. It now binds to IPv6 instead of IPv4 so we need to make some minor changes to Postfix’s configuration to get Postgrey working again.

1. First up, we need to stop mail being bounced. It’s better to have sending servers pool up mail a little and then send it all through at once later, so at a Terminal prompt on your server, type in:
   
   $ sudo service postfix stop
   
2. Now we need to edit Postfix’s configuration file:
   
   $ sudo nano /etc/postfix/main.cf
   
3. Scroll down until you can see the line inside the “smtp_recipient_restrictions” section that directs Postfix to send mail to Postgrey for checking (or use CTRL+W to search for it), which looks like this:
   
   check_policy_service inet:127.0.0.1:10023,
   
4. And now modify that line to look like the following. This will make Postfix pass on the mail to Postgrey using IPv6 instead of IPv4:
   
   check_policy_service inet:::1:10023,
   
5. Now on a new line outside of the “smtp_recipient_restrictions” section, add the following line:
   
   inet_protocols=all
   
6. Save your changes by pressing CTRL+X, then “Y” and then Enter.
   
7. Now we can restart Postfix with:
   
   $ sudo service postfix restart
   
8. Now start tailing your log with the “follow” parameter using the following command:
   
   $ tail -f /var/log/mail.log
   
9. Now send a test email and watch what new information appears in the terminal log. This time the mail should be successfully received and processed as normal.
   
10. Pat yourself on the back and breath a sigh of relief.

Scenario: You’ve setup a PXE server. You’ve setup an Ubuntu Live CD to boot over your network via PXE. Everything works well.

You then decide to install a fresh Ubuntu Desktop installation from your PXE-booted environment. All goes well. The install finishes and your system reboots.

When the system comes up, you discover that there’s no network connections. Ethernet doesn’t work, but wifi probably is working OK, or you can’t get wifi working yet because you need to install a closed-source driver for it. You check the Network Manager and find that there is no automatically defined ethernet connection such as “Auto eth0″. What’s the go?

Here’s how to fix it.

When you run a PXE environment, one of the key things that has to be configured before any startup commenced is your IP address. This is performed by your PXE agent and means that when the Ubuntu Live Environment boots up, DHCP is not employed during bootup because it would sever your connection to your NFS server where the Ubuntu Live Environment is booting from.

As a result of this, when you install from the PXE-booted Live Environment, which is effectively a direct copy of the Live Environment, you also end up copying the manually-configured network setup where Network Manager is essentially told not to do anything.

So let’s fix that.

1. Once your system is installed and rebooted for the first time, open yourself a Terminal window.
   
2. Type in the following:
   
   $ sudo nano /etc/network/interfaces
   
   …and hit Enter.
   
3. You will see an entry for eth0 there looking something like this:
   
   auto eth0
iface eth0 inet manual
   
4. Since Ubuntu uses Network Manager to manage network connections, any definition listed in this file will automatically override it, so simply delete the “iface” line underneath “auto eth0″, but leave the “auto eth0″ line intact.
   
5. Save your changes by pressing CTRL+X, then Y and then Enter.
   
6. Restart your PC.
   
7. Upon restarting, your system should now show a working ethernet connection as normal with all connectivity restored.
   
8. Pat yourself on the back. You are done.

You may notice on some systems you build that when you SSH into them, there seems to be a long delay before the system prompts you for your password. In a time-sensitive situation, this gets real frustrating, real fast.

Here’s how to fix it.

The issue is caused by the box you are SSHing into trying to resolve your IP address to a DNS name for the logs. We don’t really need this (especially for non-public servers), so we may as well disable it, drastically speeding up the time it takes for the box to prompt you for your password in the process (so drastic it becomes instant, in fact).

1. Login to your box as normal via SSH.
   
2. Type in at the dollar prompt:
   
   $ sudo nano /etc/ssh/ssh_config
   
3. A text editor showing you the SSH server config will appear. Scroll right to the very bottom of the file.
   
4. Now add the following line in (indent it to match the existing lines with a few spaces at the front):
   
   UseDNS no
   
5. Save your changes by pressing CTRL+X, then “Y” and then Enter.
   
6. Restart the SSH server with the following command (won’t affect your existing session):
   
   $ sudo service ssh restart
   
7. Log out and test logging in via SSH again. This time the password prompt will appear immediately.
   
8. Pat yourself on the back. You’re done.

This fix applies to any version of Ubuntu (or just about any distro, for that matter).

Diskless booting is where a PC starts up purely from a network connection. It does not have a physical hard-drive in it to start from in the traditional manner.

Why would you want to do this? Well, say for example you have a MythTV Frontend PC. For the most part, most Frontends are dedicated PC’s connected to a TV or projector that are not used for any other purpose, so technically there is really no need to have a hard-drive inside one as nothing new will ever be stored (all the media is streamed from the Backend server). There’s also the added bonus of less noise by not having a hard-drive installed.

Another good example of using a Diskless boot environment is for performing offline virus scans of Windows based PC’s in a safe environment that is not Windows, using tools like ClamAV. In a corporate environment, having a “normal” installation makes it easier to setup default settings that normally don’t suit booting up from an Ubuntu Live CD, such as corporate Proxy settings. Making a Diskless Boot setup is far easier than creating a customised Live CD in this instance.

So how exactly do you create a diskless booting PC?

Pre-requisites:

• First up, you need a working PXE server. If you haven’t built one yet, you can refer to my previous tutorial on how to build one.
• Sufficient space to store a typical Ubuntu Desktop install. I would recommend having at least 10GB free to allow space for both the OS and any additional apps you might install.
• A PC that you will using as your diskless machine that has the ability to boot from PXE.
• A temporary hard-drive for your diskless machine that we will be using to do our initial build on.
• A fast network. Diskless booting is only useful if your network can transfer data quickly. I would recommend that you use a gigabit network.
• It is recommended to have at least 2GB RAM on your diskless PC, primarily because we will not be running a swap file or swap partition (swapping over a network connection is just silly).
• Ubuntu 10.04.2 LTS was used for this tutorial, but you should be able to use just about any release of Ubuntu. Note: The version of Ubuntu on your PXE server and the version of Ubuntu you are turning into diskless boot does not have to be the same version, but I would recommend using 10.04.2 LTS or later.

What to do:

1. First up, install the temporary hard-disk into your PC that is going to become diskless. You can attach it in the traditional way or connect it via USB.
   
2. Perform a normal installation of Ubuntu Desktop Edition onto the hard-drive of your PC.
   
3. Once installed, update the system with any outstanding system updates.
   
4. Install any additional apps you wish to utilise on this machine, such as MythTV.
   
5. Once you are satisfied that your installation is setup the way you want it, we need to prepare the installation to be able to boot via PXE. Start by opening up a terminal and type in the following commands:
   
   $ cd ~
$ sudo nano /etc/initramfs-tools/initramfs.conf
   
6. You will now be looking at a text configuration file in the Nano text editor. This is the configuration file that controls how the boot-time RAM disk image is created. We need to modify it so that we can create a PXE-ready version of the RAM disk image instead of the usual type. Scroll down until you find the configuration line that looks like:
   
   MODULES=most
   
   …and modify it so that is now looks like:
   
   MODULES=netboot
   
7. Scroll down a little further until you see the line:
   
   BOOT=local
   
   …and change it to read:
   
   BOOT=nfs
   
8. Press CTRL+X, then “Y” and then “Enter” to save your changes. You will be returned to the Terminal prompt.
   
9. Now let’s create our custom RAM Disk image using the following command:
   
   $ sudo mkinitramfs -o ./initrd.img
   
10. Once that has finished, we also need an unmodified copy of the current kernel you are running:
    
    $ cp /boot/vmlinuz-`uname -r` ./vmlinuz
    
11. Now we need to prep the server. First up, we need to setup a way to transfer our temporary hard-disk contents to the PXE server, and we also need to ready how the PXE server will serve the data to the diskless workstation when booting. We will be using the Network File System, or NFS for short. On your Ubuntu PXE Server, open a terminal and type in the following:
    
    $ sudo apt-get install nfs-kernel-server
    
12. Once the NFS server is installed, we need to setup the directory that will store and serve the Diskless system’s files. Assuming you have all your PXE related data under /srv/tftp, let’s create the following for our Diskless station data:
    
    $ sudo mkdir -p /srv/nfs/disklessboot
    
13. Now let’s tell the NFS server about this new directory:
    
    $ sudo nano /etc/exports
    
14. In the text file that appears in the Nano text editor, scroll to the bottom of the file and add the following line:
    
    /srv/nfs/disklessboot          *(rw,no_root_squash,async,no_subtree_check)
    
    The above will allow read/write access to the path /srv/nfs/disklessboot on your PXE server from any incoming IP address.
    
15. Save your changes by pressing CTRL+X, then “Y” and then “Enter”.
    
16. Now activate the new NFS shareby using the following command:
    
    $ sudo exportfs -a
    
17. We’re nearly there! Now we just need to transfer the contents of our temporary workstation hard-drive to the new NFS share. On your soon-to-be-diskless PC (not the server), and assuming that your PXE server’s IP address is 192.168.0.10, type the following in a Terminal:
    
    $ sudo apt-get install nfs-common
$ mkdir /dev/shm/nfs
$ sudo mount -t nfs -nolock 192.168.0.10:/srv/nfs/disklessboot /dev/shm/nfs
    
    The above will create a directory in your RAM disk to mount the PXE server’s NFS share on and the second command will mount the NFS share /srv/nfs/disklessboot in the directory you just created in your RAM disk locally, thus allowing you to now read and write data to that NFS share by using /dev/shm/nfs locally.
    
18. Now let’s copy the OS files from the temporary hard-disk to the PXE server’s NFS share:
    
    $ sudo cp -avx /. /dev/shm/nfs/.
$ sudo cp -avx /dev/. /dev/shm/nfs/dev/.
    
    The above commands will take a minute or two to finish and will show you a giant list of files being copied.
    
19. We are now done with the soon-to-be-diskless PC, so shut it down and remove your temporary hard-drive.
    
20. Go back to your server and type in the following at the Terminal prompt:
    
    $ sudo mkdir -p /srv/tftp/disklessboot
$ sudo cp /srv/nfs/disklessboot/home/USERNAME/vmlinuz /srv/tftp/disklessboot/
$ sudo cp /srv/nfs/disklessboot/home/USERNAME/initrd.img /srv/tftp/disklessboot/
    
    Note: Replace USERNAME above with whatever your username was on the temporary hard-disk setup, eg: “/home/jbloggs/”
    
21. We now need to change the network setup of the disklessboot install so that it doesn’t try to configure itself with a new IP address on boot (since it’ll already have one when you do the initial PXE boot):
    
    $ sudo nano /srv/nfs/disklessboot/etc/network/interfaces
    
22. Look for a reference to “eth0″ which is your first ethernetadapter. It will generally be the last line in the file and may look like:
    
    auto eth0
    …or:
    iface eth0 inet dhcp
    
23. Once you locate it, comment out that line by putting a hash symbol at the front like so:
    
    #auto eth0
    …or:
    #iface eth0 inet dhcp
    
24. Now add a new line with the following:
    
    iface eth0 inet manual
    
25. Save your changes with CTRL+X, then “Y” and then “Enter”.
    
26. Now we need to ensure that the devices mounted by your disklessbooting PC do not try to mount physical disk devices for things like /home and the root filesystem. Type in the following command:
    
    $ sudo nano /srv/nfs/disklessboot/etc/fstab
    
27. Once in the text editor, DELETE EVERYTHING and replace it all with the following:
    
    proc            /proc           proc    defaults        0       0
/dev/nfs        /               nfs     defaults        1       1
none            /tmp            tmpfs   defaults        0       0
none            /var/run        tmpfs   defaults        0       0
none            /var/lock       tmpfs   defaults        0       0
none            /var/tmp        tmpfs   defaults        0       0
    
28. Save your changes with CTRL+X, then “Y” and then “Enter”.
    
29. That’s the Diskless setup ready to go. All that we now need to do is configure the PXE boot menu to give you an option to boot Diskless. To do this, edit your PXE boot menu configuration file. Assuming you called it /srv/tftp/mybootmenu.cfg, type in the following:
    
    $ sudo nano /srv/tftp/mybootmenu.cfg
    
30. In the text editor, scroll down to the bottom of your configuration file and add the following lines:
    
    label My Diskless Boot PC
kernel disklessboot/vmlinuz
append initrd=disklessboot/initrd.img root=/dev/nfs nfsroot=192.168.0.10:/srv/nfs/disklessboot ip=dhcp rw
    
    The above menu configuration will tell PXE to load the kernel and custom RAM disk image from the TFTP directory and then transfer control of the boot process to the OS files located in /srv/nfs/disklessboot which will be mounted on the diskless system at /dev/nfs as the root filesystem.
    
31. Save your changes by pressing CTRL+X, then “Y” and then “Enter”.
    
32. Finally, make sure that the TFTP daemon can read the new files you added to it with the following command:
    
    $ sudo chmod 777 -R /srv/tftp
    
33. That’s it! You are now ready to boot! Turn on your now-diskless PC and tell it to boot from PXE. When the PXE boot menu appears, choose “My Diskless Boot PC” and watch in wonder and amazement as Ubuntu boots up without a hard-disk as if by magic!

NOTE: Whilst the Diskless PC will boot and operate much like any ordinary PC and in fact you can indeed perform future system updates this way, be aware that the kernel itself will NOT get automatically updated. Newer kernels will get installed to the NFS mount as you would expect, however the kernel actually boots from your TFTP directory, not the NFS share, so if you do update the kernel in future, you must create a new RAM disk image manually as per step 9 and copy both it and the new kernel file into your TFTP’s directory (in this case /srv/tftp/disklessboot/) otherwise your updated system will not boot anymore. Alternatively, simply allow all updates to be performed except for kernel updates.

Finally, hardware drivers: If you install the NVidia proprietary drivers for your Diskless Boot system, ensure that you don’t try to boot other systems that do not contain NVidia graphics hardware otherwise X will break. The reason for this is that the NVidia driver installation makes a number of changes to system-level libraries to work, effectively binding that system to NVidia graphics-based systems only. If you intend to use your Diskless setup on multiple hardware platforms, such as NVidia, Intel and ATi, do not install the proprietary NVidia (or ATi) driver.

Enjoy! 

Let’s say you are running a poor man’s website where you are just testing stuff but have no real intention of buying a domain name or paying your ISP to give you a static IP address.

If you want to access your test site remotely, you need to know your public IP address, however your home ISP gives you a dynamic public IP address and every time you have a power failure, or reboot your router, you are assigned a brand new public IP address. This makes it very annoying if you are testing your site remotely.

Sure, you could use a Dynamic DNS service to keep track of when your public IP address changes, but what if you have a paranoid client who does not want to use even Dynamic DNS? How do you keep track of your new public IP without having to get to your internal network to read it each time?

What you need is a way to be able to have the system send you an email with your current public IP address so that there is no guess work involved. But how do we do this?

To determine your public IP, you need to have an external site to refer to which will record your public IP as connecting to it. You could use services such as What Is My IP or similar, but we don’t want to rely on an external service, nor do we want to hammer a third-party service with requests. Basically we just want to replicate the functionality of such a site as locally as possible and then use an email tool to send the information to you in a message.

Pre-requisites:

• Access to a web space outside of your working space with an IP or address that does not change. Generally every ISP out there will grant you some small quantity of complimentary web space to store some files. If you are working for clients like I am, you can use your own server if you like (after all, this blog is served from a fixed IP with a domain name attached to it).
• A PHP interpreter in your web space’s host. If you are using your own static host on Ubuntu, Apache 2 from a normal Ubuntu install be it Desktop or Server, then you should have the PHP interpreter installed by default. If not, then install the php5 package.
• If using your own static server, you will need a web server such as Apache installed on it to serve the PHP we’ll be creating.

Now let’s look at using a simple bit of PHP to obtain the address of the connecting host.

1. On your external static web space (not your local dynamic site), create a new text file somewhere readily available called getmypublicip.php or similar.
   
2. In your favourite text editor, copy and paste in the following PHP code:
   
   <?php
$ip = getenv("REMOTE_ADDR");
echo $ip;
?>
   
3. Save your changes and exit the text editor.
   
4. Test your new PHP file by referring to it from your ISP’s webspace, eg: If your ISP’s website was called myisp.com and you had a login called “noddy”, then the address to your webspace might be http://www.myisp.com/~noddy/getmypublicip.php, so type that in your web browser, which is usually the path most ISP’s use.
   
5. When you go to that URL, the PHP on the remote side should parse the referring public IP address and echo it to the page. In this case, because you are referring yourself, you should see your own public IP address (let’s say it’s 74.125.237.84 for the purposes of this guide) printed at the top-left of the web browser page.
   
   If you ran this PHP locally, you would get the internal IP of the connecting host instead, eg: 192.168.0.100 or similar instead.
   
6. Awesome, so now how do we email this newly obtained information to ourselves? Simple. We will make use of a neat little command line tool called sendemail (not to be confused with the venerable sendmail). It’s not installed in Ubuntu by default, so install it with:
   
   $ sudo apt-get install sendemail
   
7. Let’s create the script that will use sendemail. On your local test website, create a new text file outside of your web-accessible directories, eg: /home/noddy/getpublicip.sh using your favourite text editor.
   
   $ nano /home/noddy/getpublicip.sh
   
8. In the text editor, copy and paste the following in:
   
   #!/bin/bash
wget -O- http://www.myisp.com/~noddy/getmypublicip.php 2>/dev/null | sendemail -u "Client's public IP address" -f test@blah.com -t noddy@mycompany.com -s mail.mycompany.com
   
9. Save your changes and exit your text editor.
   
10. Now test your script my manually running it using the following command:
    
    $ sh /home/noddy/getpublicip.sh
    
11. Check your personal email. You should have received an email sent by test@blah.com containing a single line showing your public IP address!
    
12. Now we need to setup the script to be executed periodically. We will setup a cron schedule to run our new bash script as follows:
    
    $ crontab -e
    
13. Your text editor will appear. In this, add the following line on the end:
    
    0 * * * * sh /home/noddy/getpublicip.sh
    
14. Save your changes and exit your text editor.
    
15. Now wait. On the next whole hour, you should receive an email in your mailbox containing a single line with an IP address – your public IP address! Now you need never know what your private server’s public IP address is if it changes in the middle of the day – on the hour you will be told what it is!
    
16. If you’d like to receive notification on a more regular basis, modify the cron schedule. For example, the following change to step 13 will make your system run the script every 15 minutes:
    
    */15 * * * * sh /home/noddy/getpublicip.sh
    
17. That’s it! Pat yourself on the back. You’re done.

NOTE: Some ISP’s do not allow connections on dynamic IP’s to send periodic email on their mail server and may block it on the belief that your emails may be spam. Should that be the case, you should install a local mail daemon such as Postfix and change the sendemail arguments to direct their mail to localhost instead, and allow Postfix to send the notification email. In Ubuntu, you can install Postfix by simply installing the postfix package and electing the server to be an “Internet Site”. The default configuration is fine, but not secure. Ensure that no-one externally can access port 25 on your client’s server if you choose to go down this route.

The dd command is a tool used to pipe data in from a source to a destination. It has a multitude of uses ranging from creating large dummy files of a specific size to duplicating hard-drives sector by sector to another disk or to a backup file. It’s also useful for fixing problems with hard-drives that Windows refuses to deal with.

But we’re not looking at the virtues of dd here. We’re looking at its annoyances and dd has one particularly glaring annoyance – a lack of display of progress. You could tell dd to start imaging your multi-terabyte hard-drive and not have any indication of how far it has gone – you just have to wait until it finishes. The dd command only outputs some information right at the very end of its job, which could well be several hours later. The only indicator that you have that something is happening is your hard-drive light madly flashing away.

Luckily while dd doesn’t show progress during its tasks, it can be prodded externally to give up information about itself as it runs, and we can achieve that by using the kill command without actually killing the dd command’s execution.

Now the kill command doesn’t just terminate tasks. It can also send other standard POSIX signals to applications. Many applications are written to acknowledge certain signals and perform an action on receiving them. In the case of dd, there is one signal that will make it output its summary information to the console as though it had finished, but rather than terminate, it keeps on going. The signal in question is USR1.

Here’s how to make use of it:

1. First we need a dd process running. Let’s say we are imaging our first fixed hard-drive /dev/sda to an image file called MyHDDBackup.img using the following command:
   
   $ sudo dd if=/dev/sda of=/home/jbloggs/MyHDDBackup.img
   
2. Now while that is running, open up a second terminal and type in the following followed by Enter:
   
   $ sudo kill -USR1 `pgrep ^dd`
   
   Breakdown of the above command:
   • sudo runs this command as root. In this case since we’re using dd as root, we also need to run the kill command as root or we won’t be able to send anything to dd.
   • kill is the command we are using to send dd a signal with.
   • -USR1 is the signal we are sending to dd.
   • pgrep is a program that will show you the process ID of a given application, in this case we use the argument “^dd” to say “locate any program that starts with the text ‘dd’ only” otherwise we would get other processes that containg the letters “dd” together in their name if we left out the chevron character. Note that the pgrep command is enclosed in “`” quotes so that it is executed and returns just a process ID number to the kill command.
     
3. Now have a look at the terminal that dd is running in. It has suddenly output some data about itself, specifically, how much of the task had been completed, but dd is still running!
   
   This is great – but how can we regularly have dd tell us where it’s up to without having to manually enter the above command each time? Simple, by combining it with the watch command:
   
   $ watch 'sudo kill -USR1 `pgrep ^dd`'
   
   The watch command will will re-execute the kill command once every two seconds, giving you near-realtime status to what dd is doing. If you want to change how often the watch command polls for, you can change it with the -n parameter, for example to change the polling to every 5 seconds, you would use:
   
   $ watch -n5 'sudo kill -USR1 `pgrep ^dd`'

While not providing any means of showing you how long it will take for dd to ultimately finish, you can now make use of the transfer speed shown along with the data processed thus far and calculate a rough idea of when dd will complete its task now.

Pat yourself on the back. You can now rest easy knowing that you can find out at anytime where dd is up to. 

It’s been a while since I’ve written something here, so time to break the drought.

APC make some great UPS products and they all have the ability to communicate with a host PC to advise of its state, eg: on mains, on battery, fault, etc. The support software is available aplenty for Windows and Mac, but what about Linux?

This guide will show you how to hook up an APC UPS to an Ubuntu-based Desktop or Server PC and allow your UPS to email you when mains power has failed, when mains power has been restored, and also give your PC ample opportunity to shutdown when battery on the UPS gets to a critical low.

Pre-requisites:

• Ubuntu-based PC. I am using Ubuntu 10.04 Lucid Lynx in this guide.
• An APC UPS. I’m using a Back-UPS RS 800 in this guide.
• Details about your ISP’s mail server, or your own local mail server.

Configuration:

1. Setup your APC UPS as outlined in the instruction manual. Ensure that the USB or serial cable is connected from the UPS to the PC. This is what the UPS uses to communicate with the PC.
   
2. On your Ubuntu PC, go into a Terminal. If you are using Ubuntu Desktop, you can do this by going to the Applications menu, then Accessories and then Terminal. If you are using Ubuntu Server, simply login to your server by the console or SSH in remotely.
   
3. The Ubuntu repositories contain a UPS daemon specifically designed with APC UPS units in mind called APCUPSD, so let’s install it:
   
   $ sudo apt-get install apcupsd
   
4. Once installed, we need to configure it to suit your UPS. Bring up the configuration file by typing in:
   
   $ sudo nano /etc/apcupsd/apcupsd.conf
   
5. In the editor, scroll down to UPSNAME and give the UPS a name, eg:
   
   UPSNAME MyAwesomeUPS
   
6. Scroll down to UPSCABLE and change the parameter to the type of cable you are using to connect to your UPS. In my case, I use a USB cable that came with the UPS, so I changed this line to read:
   
   UPSCABLE usb
   
7. The next line to modify is the UPSTYPE line. Again, because I’m using USB I specify:
   
   UPSTYPE usb
   
   If you have a DEVICE /dev/ttyS0 line after the UPSTYPE line, comment it out by adding a hash symbol at the start of the line like so:
   
   #DEVICE /dev/ttyS0
   
8. We do not need to modify anything else, so press CTRL+X, then “Y” and then Enter to save your changes and exit the Nano text editor.
   
9. Now we need to tell the system that the UPS daemon has been setup and is essentially ready to go. Type in:
   
   $ sudo nano /etc/default/apcupsd
   
10. In the file that appears, modify the ISCONFIGURED line to say Yes”, ie:
    
    ISCONFIGURED=yes
    
11. Press CTRL+X, then “Y” and then Enter to save your changes and exit.
    
12. We’re pretty much done here. Start the daemon now with the following command:
    
    $ sudo service apcupsd restart
    
    …or simply reboot your PC. Your PC is now monitoring the state of the UPS.
    
13. Let’s check the UPS now. Type in the following command:
    
    $ apcaccess
    
    …and you will get output similar to the following:
    
    $ apcaccess
APC      : 001,043,1045
DATE     : Tue Feb 01 00:02:36 EST 2011
HOSTNAME : lamaar
VERSION  : 3.14.6 (16 May 2009) debian
UPSNAME  : LAMAAR
CABLE    : USB Cable
MODEL    : Back-UPS BR  800
UPSMODE  : Stand Alone
STARTTIME: Mon Jan 31 23:43:37 EST 2011
STATUS   : ONLINE
LINEV    : 250.0 Volts
LOADPCT  :  40.0 Percent Load Capacity
BCHARGE  : 100.0 Percent
TIMELEFT :  19.9 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
OUTPUTV  : 230.0 Volts
SENSE    : Medium
DWAKE    : 000 Seconds
DSHUTD   : 000 Seconds
LOTRANS  : 194.0 Volts
HITRANS  : 264.0 Volts
RETPCT   : 000.0 Percent
ITEMP    : 29.2 C Internal
ALARMDEL : Always
BATTV    : 27.4 Volts
LINEFREQ : 50.0 Hz
LASTXFER : Low line voltage
NUMXFERS : 0
TONBATT  : 0 seconds
CUMONBATT: 0 seconds
XOFFBATT : N/A
SELFTEST : NO
STATFLAG : 0x07000008 Status Flag
SERIALNO : xxxxxxxxxxxx
BATTDATE : 2001-09-25
NOMOUTV  : 230 Volts
NOMINV   : 230 Volts
NOMBATTV :  24.0 Volts
NOMPOWER : 540 Watts
FIRMWARE : 9.o5 .I USB FW:o5
APCMODEL : Back-UPS BR  800
END APC  : Tue Feb 01 00:02:41 EST 2011
$
    
14. Pat yourself on the back, you’re basically done.

But hang on, what about setting up email notifications? Read on.

Setting up Email Notifications

By default, APCUPSD is configured to use sendmail to send emails, but sendmail is finicky. There is a better way using a similar application called sendemail instead.

Why use sendemail instead of sendmail? Well, sendemail is a simple command-line SMTP client. You construct a simple message with a recipient and off it goes, but the key difference here is that sendemail is a CLIENT, not a SERVER. This means for sendemail to work, you need a third-party mail server to send it through. You may already have a mail server on your network running Postfix or similar. If not, your ISP will most certainly have one that you can use.

1. Let’s start by installing sendemail:
   
   $ sudo apt-get install sendemail
   
2. Now we need to configure apcupsd to use it. If you have a look inside the /etc/apcupsd directory, you will see several important files as follows:
   • changeme – notifies you if the UPS battery needs changing.
   • commfailure – notifies you if the PC loses communication with the UPS.
   • commok – notifies you if lost communication is restored with the UPS.
   • onbattery – notifies you if the UPS engages battery mode due to mains power failure.
   • offbattery – notifies you if the UPS returns to mains mode after a mains power failure.
     
3. Let’s modify the onbattery message:
   
   $ sudo nano /etc/apcupsd/onbattery
   
4. You will notice there are some lines in this file that define some variables followed by a message and then finally a command that sends an email using the sendmail app. Since we are not using sendmail, we need to modify a number of areas. Replace the content of the entire text file with the following:
   
   #!/bin/sh
#
# This shell script if placed in /etc/apcupsd
# will be called by /etc/apcupsd/apccontrol when the UPS
# goes on batteries.
#
SYSADMIN=jbloggs@mydomain.com.au
APCUPSD_MAIL="/usr/bin/sendemail"
HOSTNAME=`hostname`
MSG="Ubuntu PC Power Failure !!!"
#
(
echo " "
echo " ====================================="
echo " POWER FAILURE ON $HOSTNAME !!"
echo " ====================================="
echo " "
echo "The UPS on your Ubuntu PC has experienced a power problem that has required the UPS to engage battery mode."
echo " "
echo "Do not panic! Remain calm..."
echo " "
echo "Current UPS status:"
echo " "
/sbin/apcaccess status
) | $APCUPSD_MAIL -u "$MSG" -f MyUbuntuPC@mydomain.com.au -t $SYSADMIN -s mail.myisp.com:25
exit 0
   
   So what have we done here? The first part of the file sets some variables, namely the email address(es) of the people required to be notified. If you need to send to more than one recipient, separate email addresses with a comma, eg:
   
   SYSADMIN=jbloggs@mydomain.com.au,fredsmith@thatotherdomain.com
   
   We then define the path to the sendemail app, the hostname of the PC running the UPS daemon, a subject line for the email in question, and then a big email body explaining what’s going on, in this case that the UPS battery mode has been engaged.All this is then piped into the sendemail application with a fake sender’s address to give you an idea where it came from and we also specify the mail server that the email will be sent via. In this case, we are using our ISP’s mail server that has the address mail.myisp.com
   
5. Save your changes by pressing CTRL+X, then “Y” and then Enter.
   
6. You can now test the script by simply executing it (we don’t have to disconnect the UPS’ mains cable to trigger this until we’re ready to test that). Execute the file using the command:
   
   $ sh /etc/apcupsd/onbattery
   
7. Check for any errors and then check to see if you got an email in your mailbox advising that the UPS is on battery (the UPS of course is not, we’re just testing the email).
   
8. If all is well, continue to change the other four message files to be similar to the above, changing the message as you go of course.
   
9. Pat yourself on the back – you now have custom, explicit messages to let you know what’s going on with the UPS.

Setting up your own mail server to use instead

If, in your testing, you discover that your ISP’s mail server does not allow you to randomly spam messages to it using fake from addresses, you have two choices – either specify a valid email address as the sender’s address, or you can setup a simple email server of your own using Postfix:

$ sudo apt-get install postfix

In the case of setting up your own email server, simply go with Postfix and set it up as an “Internet Site”. The basic configuration is good enough to deal with our needs, but make sure your basic network security is adequate to prevent outsiders from trying to use your mail server to send unsolicited mails, or spam, through it.

This article will not describe how to setup or secure Postfix as it is beyond the scope of this article, however you do need to modify the outgoing mail server name in all your communication messages to reflect the change of name or internal IP address of your mail server instead of mail.myisp.com.

Testing

You can test your daemon setup easily enough by doing any of the following:

• Remove mains power cable from UPS.
• Remove the USB cable to the UPS.
• Verify that an email is sent for either of the error conditions above.

Enjoy! 

Yes, you read that right – there is finally an Open Source Blu-Ray Disc player GUI for Linux, albeit unofficial and certainly very grey in legality depending on which country you are in.

lxbdplayer is the collaborative effort of four French Engineering students. What they have written is basically a frontend that combines the apps DumpHD and AACSKeys which I have used in previous Blu-Ray articles into one easy to use GUI. Decrypted BD streams are then piped into MPlayer for playback.

The end result is that you can now watch your BD movies almost as simply as a regular video player without the need to go through the process of ripping them into an MKV file first, or chewing up loads of drive space.

Now before you get all excited, this is a work in progress and you are ultimately limited to the decryption keys that have been discovered so far. You have no better ability to watch BD titles than you have with doing it all manually with DumpHD and AACSKeys. In fact, lxbdplayer already falls over in one area (for now), and that is it has no ability to process BD+ protected discs. Attempting to watch such movies will show a partially or fully corrupted video stream.

I tried using lxbdplayer with several of my BD titles under Ubuntu 10.04, and found that it played all my older titles pretty much perfectly. It’s only newer titles, especially those featuring BD+ protection that are problematic.

In short, this tool will only let you play older BD titles easily, but no doubt as DumpHD and AACSKeys progress in development, we will see those improvements filter down to lxbdplayer. I should also point out that lxbdplayer does not actually play the disc as such – it pulls out the titles available on the disc and allows you to play them by choosing them from a menu. It will not actually allow you to play the menu interfaces provided on the disc.

Your BD optical drive will also need to have been hacked with custom firmware to ignore the Player certificate, or use an imported BD drive that already ignores the Player certificates, or AACSKeys will not be able to retrieve the decryption key to decrypt the disc with.

Anyway, to use lxbdplayer, you will need to download the following:

• The lxbdplayer itself. This package is a .deb for Ubuntu and Debian.
• The AACSKeys plugin for lxbdplayer.
• The MakeMKV package (this is the 64-bit version. To get the 32-bit version, click here).
• The ShowKeys library (again, this is the 64-bit version. To get the 32-bit version, click here).

1. Install the packages by either double-clicking on them and let the GDebi installer install them, or use a terminal as follows:
   
   $ sudo dpkg -i lxbdplayer_0.2.1_all.deb lxbdaacs_0.2.1_all.deb makemkv_1.5.5b_amd64.deb libshowkeys_v1.5.5_amd64.deb
   
2. A couple of dependencies will need to be downloaded, but otherwise the installation is small and quick.
   
3. Once the install is complete, import the decryption keys needed by typing in the following command (you do not need to use sudo here):
   
   $ bdkey-install
   
4. Now you are ready to rock and/or roll.
   
5. Insert your BD movie disc into your BD drive. Within seconds you should be prompted by Gnome about what to do with the disc, and you will notice that there is a new default action for BD discs to launch lxbdplayer. Go ahead and allow lxbdplayer to launch, or alternatively launch it manually from Applications->Sound & Video->lxBDPlayer. If you manually launch, you need to tell the player where your BD title is mounted. Under Ubuntu Lucid, this will be under the /media directory.
   
6. Once your BD disc is located, lxbdplayer will process the disc for a short while before presenting you with a chapter list. To play a title, simply choose it from the list and hit the Play button. Almost right away you will see the video appear on your screen.

The player showing the video itself is simply MPlayer, and all its standard controls apply here.

Pat yourself on the back – and enjoy your movies. 

More information about lxbdplayer including screenshots, can be found on the project’s home page, but be warned, it’s all in French.

Following my article about creating your own PXE network boot server, here is the first practical use you can put it to – taking the Ubuntu Live CD and turning it into a network-bootable version!

Network booting the Live CD has obvious advantages – aside from booting faster than CD (especially on a gigabit network), it is indispensable as an emergency boot medium in a workplace environment, especially for broken Windows systems, and allows for Ubuntu effortless installations on netbook PC’s that don’t have optical drives and saves you having to have a USB stick handy.

Pre-requisites

• You need a working Linux PXE boot server. Doesn’t have to be Ubuntu, but it needs to be Linux. You cannot use a Windows PXE server.
• An Ubuntu 10.04 Live CD ISO or physical CD. Can be the 32-bit or 64-bit ISO, but you can also setup both of them at once!
• At least 700MB of drive space on your PXE server, more if you want to have more than one CD available.
• This tutorial was put together using Ubuntu Server 10.04 Lucid Lynx, but should work with all future releases and older versions to at least Ubuntu Server 8.04 Hardy Heron.

Getting it together

1. Login to your PXE server and mount the CD or ISO image (in this example we are copying the 32-bit disc). Assuming the CD is mounted at /media/cdrom, copy the CD’s files to your server as follows:
   
   $ sudo mkdir -p /srv/tftp/ubuntu-livecd-boot/i386
$ sudo mkdir -p /srv/ubuntu-livecd/i386
$ sudo cp -av /media/cdrom/* /srv/ubuntu-livecd/i386
$ sudo cp -av /media/cdrom/.disk /srv/ubuntu-livecd/i386
$ sudo cp -av /media/cdrom/casper/initrd.lz /srv/tftp/ubuntu-livecd-boot/i386
$ sudo cp -av /media/cdrom/casper/vmlinuz /srv/tftp/ubuntu-livecd-boot/i386

1. (if you want to setup the 64-bit disc, then replace all instances of “i386″ with “amd64″, or you can setup both architectures by setting up both directories)
   
2. Make sure the permissions of the files to be loaded by TFTP are correct:
   
   $ sudo chmod 777 -R /srv/tftp
   
3. The astute of you will have noticed that we have copied the Ubuntu CD outside of the TFTP directory and that we have made a separate copy of only two of the disc’s files inside the TFTP directory. Why is this? Well, the vmlinuz and initrd.lz files are the only files that TFTP will need to download to get started with the boot process. After that, we will use NFS to deliver the rest of the Live CD, so let’s set that up:
   
   $ sudo apt-get install nfs-kernel-server
   
   Note: I should point out that the files that are copied to the NFS share do not have to be on the PXE server. The NFS server can be any box as NFS is not related to PXE at all.
   
4. Once that is installed, we need to define an NFS share. This is done in the NFS exports file, so let’s get that into a text editor:
   
   $ sudo nano /etc/exports
   
5. Add the following line to the bottom of the file:
   
   # Ubuntu Live CD files for PXE booting
/srv/ubuntu-livecd/i386        *(ro,async,no_root_squash,no_subtree_check)
   
   …if you are setting up the 64-bit version, replace “i386″ with “amd64″, or if setting up both architectures, list it as follows:
   
   # Ubuntu Live CD files for PXE booting
/srv/ubuntu-livecd/i386        *(ro,async,no_root_squash,no_subtree_check)
/srv/ubuntu-livecd/amd64       *(ro,async,no_root_squash,no_subtree_check)
   
   A breakdown of the parameters on the right is as follows:
   • The asterisk means “share with everyone on this network, regardless of who they are”.
   • The “ro” parameter means to share the data as read-only.
   • The “async” parameter allows the NFS server to reply before data is written to the share. Since it’s mounted as read-only anyway, the parameter is only there to keep NFS’ syntax happy.
   • The “no_root_squash” parameter means to allow the NFS client to use the mount as a root filesystem, otherwise it’s mounted as “nobody” instead of “root”. Since the LiveCD is essentially a diskless client, we need to be able to define the NFS mount as a root volume.
   • The “no_subtree_check” parameter helps to speed up transfers. Normally NFS will check to see if a requested file exists in an exported sub-directory. This slows things down, so turning this off means the only check that is made is that the requested file exists on the exported filesystem. Subtree checking can also cause issues when an open file is renamed, but since the export is read-only, this is irrelevant.
     
6. Save your changes with CTRL+X, then “Y” and then Enter.
   
7. Now have NFS re-read its export file and begin sharing the specified directories with:
   
   $ sudo exportfs -a
   
8. We’re nearly ready to rock and/or roll. All we need to do now is prepare the PXE boot menu to launch the Live CD for us. Assuming you followed by previous tutorial and your boot menu file is called mybootmenu.cfg:
   
   $ sudo nano /srv/tftp/mybootmenu.cfg
   
9. Assuming your NFS server’s IP address is 192.168.0.10, insert the following lines for a 32-bit Live CD entry:
   
   label Live CD 32-bit
    kernel ubuntu-livecd-boot/i386/vmlinuz
    append boot=casper netboot=nfs nfsroot=192.168.0.10:/srv/ubuntu-livecd/i386 initrd=ubuntu-livecd-boot/i386/initrd.lz -- splash quiet
   
   …and if you are doing 64-bit, you can replace or add as a separate menu option the following:
   
   label Live CD 64-bit
       kernel ubuntu-livecd-boot/amd64/vmlinuz
       append boot=casper netboot=nfs nfsroot=192.168.0.10:/srv/ubuntu-livecd/amd64 initrd=ubuntu-livecd-boot/amd64/initrd.lz — splash quiet
   
   The kernel line is the actual kernel that is loaded to run the session. The append line tells the boot process several things. First up, the casper directory contains the boot files (a SquashFS image in the case of the Live CD), the root of the NFS file system is located on the server with the IP 192.168.0.10 under the path /srv/ubuntu-livecd/i386 (or amd64) and that the image to fire up the RAM disk with is located under ubuntu-livecd/i386/initrd.lz and finally we have advised the boot process to suppress console messages and display the splash screen while loading. From this point on, the initrd.lz is extracted and will grab the SquashFS image from the casper directory via NFS, extract it and commence running it. All other files that the disc needs to do its thing (such as when installing Ubuntu from the Live environment) are also provided by the NFS share.
   
10. Save your changes by pressing CTRL+X, then “Y” and then Enter.
    
11. You’re now ready to go – reboot your PXE workstation and you should now see an entry for your Live CD. Upon choosing it, your system should fire up with the Live environment! Once booted, you can even do an Ubuntu install to the PC you started on as though you’d booted from a CD or USB device!
    
    

Enjoy! 

The Preboot eXecution Environment (PXE) provides a means of starting up a PC using a network adapter instead of the traditional method of hard-drive, USB flash stick, CD or floppy disk.

Why would you want to boot a PC from the network? Well, it opens the door to booting diskless workstations, eg: Internet Cafe PC’s, or if you regularly install tens or hundreds of PC’s, you can start the installer on all those machines at once without needing to have individual boot/install media for each machine. You can even use Linux PXE for starting Microsoft Windows network installers and tools.

This article is going to show you how to setup a standard Ubuntu 10.04 Lucid Lynx Server (will also work with Ubuntu 12.04 and 14.04) to respond to a PXE boot request and present a boot menu ONLY. I will put practical applications such as installing Ubuntu over the network or booting a Live CD over the network into separate future articles.

Pre-requisites:

• A PC or virtual machine with an installation of Ubuntu Server on it. This tutorial was written using an Ubuntu Lucid 10.04 Server, but these instructions will work equally well on nearly any version of Ubuntu Server (tested and working on Ubuntu 12.04 and 14.04). This tutorial will not detail the initial build of a server as it is relatively straight forward.
• A DHCP server that allows you to specific PXE boot information. Most consumer routers will not give you these options. Suitable DHCP servers are the DHCP daemon on Ubuntu Server, third-party Linux router solutions such as Smoothwall or pfSense, and Windows Server among others.
• If your DHCP server is a dedicated network/firewall device that you do not wish to use as a file server to serve the network boot files, then you will need a separate PC to be a file server as well.
• Some free disk space. PXE booting take bugger-all space, but whatever you plan to serve from it will need space. If you plan to setup the Ubuntu Live CD to be bootable from PXE, you will need 700MB+ of hard-drive space on that server. You will need more than this if you wish to host things like multiple LiveCD’s such as both the 32-bit and 64-bit versions, or multiple different distributions.
• A PC workstation that has PXE boot capability. Any PC built in the last 10 years should definitely have this capability, though you may be required to enable it in BIOS. If you do not have a PC that can do this, you can use a virtual machine such as Virtualbox instead (you could have a virtual machine PXE boot off a virtual PXE boot server too!  ).
• A copy of Ubuntu Server 10.04 that suits your server’s architecture.
• A copy of the Ubuntu ALTERNATE Install CD 10.04 that we need to get some PXE boot files from. Unfortunately the Live CD does NOT contain the files we need.

At the end of this exercise we will have a PXE server that will boot into a selection menu that will give us choices of things to do. We’re also going to pretty up the menu with a background image instead of just having plain boring text, and we’ll do this using some of the existing elements on the Ubuntu CD as most of the work has been done for you already!

Getting it together:

1. Login to your server.
   
2. Let’s install the software we need:
   
   $ sudo apt-get install tftpd-hpa inetutils-inetd
   
   …this will install a Trivial FTP server which is essentially a super-simple FTP server plus the inetd daemon which will listen out for TFTP requests and direct them to the TFTP daemon.Before you ask, no you cannot use a regular FTP daemon like vsftpd or similar. It has to be a TFTP daemon. Beware: Ubuntu has two TFTP options in the repository – you must use the HPA version of the daemon as shown, as it handles large boot images while the other daemon does not. If you don’t use it, you will see boot errors.
   
3. By default Ubuntu sets up the TFTP daemon’s root directory to be /var/lib/tftpboot which may not suit your requirements. For the purposes of this tutorial, we will be changing this to /srv/tftp instead. To do this, we need to edit the /etc/inetd.conf file in a text editor:
   
   $ sudo nano /etc/inetd.conf
   
4. Scroll down to the bottom of the file and modify the tftp line (or add it if it’s missing) and substitute /var/lib/tftpboot bit on the end of that line with the path to your preferred directory:
   
   tftp    dgram   udp    wait    root    /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /srv/tftp

5. Save your changes by pressing CTRL+X and then “Y” and then Enter.
   
6. Now we need to tell the Trivial FTP daemon where our TFTP root is. Open its config file with:
   
   $ sudo nano /etc/default/tftpd-hpa
   
7. Modify the TFTP_DIRECTORY line (usually the fourth line from the top) to be /srv/tftp:
   
   # /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"
   
8. Save your changes by pressing CTRL+X and then “Y” and then Enter.
   
9. Now we just need to restart the inetd and tftp services with:
   
   $ sudo service inetutils-inetd restart $ sudo service tftpd-hpa restart
   
10. So that’s the TFTP daemon ready to serve files to a PXE agent. Now we need to create the directory where we will be putting all our PXE goodness into:
    
    $ sudo mkdir -p /srv/tftp
    
11. We now need to copy some files off the Ubuntu Alternate Install CD that make up the PXE boot files and the menu config files. I will use the 32-bit disc in this example, though the files are the same on the 64-bit disc for this step. Insert the CD or mount the downloaded Ubuntu Alternate Install CD ISO. In this case I will assume you have a physical CD mounted at /media/cdrom.
    
    $ sudo cp /media/cdrom/install/netboot/pxelinux.0 /srv/tftp
$ sudo mkdir -p /srv/tftp/ubuntu-installer/i386
$ cd /media/cdrom/install/netboot/ubuntu-installer/i386
$ sudo cp -R boot-screens /srv/tftp/ubuntu-installer/i386
$ sudo cp initrd.gz linux /srv/tftp/ubuntu-installer/i386
    
    (if you’re using the 64-bit CD, substitute all instances of “i386″ above with “amd64″ instead.)
    
12. Now we need to setup the initial PXE boot process:
    
    $ sudo mkdir /srv/tftp/pxelinux.cfg
$ sudo nano /srv/tftp/pxelinux.cfg/default
    
13. You will now be looking at a blank text editor. In this, type the following:
    
    include mybootmenu.cfg
default ubuntu-installer/i386/boot-screens/vesamenu.c32 prompt 0
timeout 100
    
    The timeout 100 line will provide a 10 second countdown before it automatically chooses the default PXE menu option when you boot into it. If you do not want a timeout, then change this to timeout 0 instead.
    
14. Press CTRL+X and then “Y” and then Enter to save your changes.
    
15. Now let’s setup our actual boot menu that we’ll be choosing options from:
    
    $ sudo nano /srv/tftp/mybootmenu.cfg
    
16. Again you’ll be looking at a blank text editor. Type (or copy & paste) in the following. Indenting text is not important, but makes it more readable:
    
    menu hshift 13
menu width 49
menu margin 8
menu title My Customised Network Boot Menu
include ubuntu-installer/i386/boot-screens/stdmenu.cfg
menu begin Cool options
    default myfirstoption
    label myfirstoption
        menu label This is a menu item
    label mysecondoption
        menu label This is another option
menu end
    
17. Press CTRL+X, then press “Y” and then Enter to save your changes.
    
18. Finally, we need to change the permissions of all files concerned because TFTP will not read any files unless they are set to full access:
    
    $ sudo chmod 777 -R /srv
    
19. That’s PXE server side ready to go. Now we need to tell PXE clients where to find the PXE boot server. If you are NOT using Ubuntu as your DHCP server, then skip to step 23, otherwise do the following:
    
    $ sudo nano /etc/dhcp3/dhcpd.conf
    
20. This opens up the DHCP config file into your text editor. Assuming your PXE server is at 192.168.0.10, scroll right to the very bottom of this file and add the following:
    
    next-server 192.168.0.10;
filename "pxelinux.0";
    
    (note the semi-colon on the end)
    
21. Press CTRL+X, then “Y” and then Enter to save your changes.
    
22. Restart the DHCP daemon with:
    
    $ sudo service dhcp3-server restart
    
23. If you’re using a non-Ubuntu DHCP server, then look for any “network boot” options and specify the PXE boot server’s IP address and path to the pxelinux.0 file there. For example, in Smoothwall, you would go to Services->DHCP and then check the “Network boot enabled” checkbox, then specify “192.168.0.10” (to suit our tutorial) into the “Boot server” box and “pxelinux.0″ in the “Boot filename” box and “/srv/tftp” in the “Root path” box.

24. We should now be ready to try out our PXE boot server! On your test workstation or VM, enable booting off the network (in the case of PXE booting a Virtualbox VM, you must ensure that the network adapter is set to “bridged mode” instead of “NAT” and fire away. You should first see your PC launch its PXE agent, looking for a DHCP server to tell it where the PXE server is:

25. If your PXE server is working, within a few seconds you will see your boot menu!

25. …and if you hit Enter on “cool options” you will now see a sub-menu showing your two options that we created.

26. Well this is all well and good, but the menu currently doesn’t actually DO anything other than show us a bunch of options. How about we provide something, say the Memory Test application from the Ubuntu Alternate Install CD? Plus we’ll add an option to boot from the first HDD in your system. If your CD is still mounted on the server, then go back into the terminal you’ve been working in and copy over the MemTest app as follows:
    
    $ sudo cp /media/cdrom/install/mt86plus /srv/tftp
    
27. Now let’s add a menu entry for it:
    
    $ sudo nano /srv/tftp/mybootmenu.cfg
    
28. Modify the file so that it now looks like the following (add just the bolded lines):
    
    menu hshift 13
menu width 49
menu margin 8
menu title My Customised Network Boot Menu
include ubuntu-installer/i386/boot-screens/stdmenu.cfg
label Boot from the first HDD
    localboot 0 label Memory Tester
    kernel mt86plus
menu begin Cool options
    default myfirstoption
    label myfirstoption
        menu label This is a menu item
    label mysecondoption
        menu label This is another option
menu end
    
29. Save your changes and exit.
    
30. Ensure the permissions of everything, including our newly copied files, have the correct permissions for TFTP to work:
    
    $ sudo chmod 777 -R /srv
    
31. Reboot your test PC via PXE and this time you will see your menu sports the new menu options at the top (you could have equally placed them at the bottom too):

32. Choosing “Memory Tester” from the menu will launch the MemTest app straight away, just like off the CD.
    
    But by now you are probably wondering “Aren’t we building off Ubuntu 10.04? Why does the menu have the old logo on it? Can we change it?”
    
    Sure, we can!
    
33. The Ubuntu 10.04 installer CD has got the new Ubuntu logo, but for some reason it’s only saved as a PCX file which won’t work for the PXE boot menu. We can fix this by simply re-saving the PCX file as a PNG file. To start with, get a copy of the splash.pcx file from the /isolinux directory on the Ubuntu CD. This is the new Ubuntu logo that you normally see on the CD’s boot menu.
    
34. Load this file into an image editor such as The GIMP and re-save it as a PNG file, eg: splash.png (of course there’s nothing stopping you from creating your own graphic either – just make sure it’s no greater than 640×480 in size and indexed down to 16 colours).
    
35. Copy the re-saved image file into /srv/tftp/ubuntu-installer/i386/boot-screens and overwrite the original splash.png file.
    
36. Ensure that the permissions of the newly added file is set correctly again with:
    
    $ sudo chmod 777 -R /srv/tftp
    
37. And when you reboot your PXE workstation again, your menu will now look like:
    

32. And there you have it. A working PXE server with menu!

I will document further uses of the PXE boot facility in future articles, including how to boot the Live CD environment without the CD or a USB key, setup the ability to use your local Ubuntu mirror as an installation source for new installs, how to launch tools like Clonezilla and DBAN, and also how to setup a diskless boot system that uses PXE to do a normal Ubuntu desktop boot directly off the network without a local hard-drive.

Stay tuned!