Canonical Voices

What Inert Ramblings talks about


Note: Community TFTP documentation is on the Ubuntu Wiki but this short guide adds extra steps to help secure and safeguard your TFTP server.

Every Data Centre Engineer should have a TFTP server somewhere on their network whether it be running on a production host or running on their own notebook for disaster recovery. And since TFTP is lightweight without any user authentication care should be taken to prevent access to or overwriting of critical files.

The following example is similar to the configuration I run on my personal Ubuntu notebook and home Ubuntu servers. This allows me to do switch firmware upgrades and backup configuration files regardless of environment since my notebook is always with me.

Step 1: Install TFTP and TFTP server

$ sudo apt update; sudo apt install tftp-hpa tftpd-hpa

Step 2: Configure TFTP server

The default configuration below allows switches and other devices to download files but, if you have predictable filenames, then anyone can download those files if you configure TFTP Server on your notebook. This can lead to dissemination of copyrighted firmware images or config files that may contain passwords and other sensitive information.

# /etc/default/tftpd-hpa


Instead of keeping any files directly in the /var/lib/tftpboot base directory I’ll use mktemp to create incoming and outgoing directories with hard-to-guess names. This prevents guessing common filenames.

First create an outgoing directory owned by root mode 755. Files in this directory should be owned by root to prevent unauthorized or accidental overwriting. You wouldn’t want your expensive Cisco IOS firmware image accidentally or maliciously overwritten.

$ cd /var/lib/tftpboot
$ sudo chmod 755 $(sudo mktemp -d XXXXXXXXXX --suffix=-outgoing)

Next create incoming directory owned by tftp mode 700 . This allows tftpd-hpa to create files in this directory if configured to do so.

$ sudo chown tftp:tftp $(sudo mktemp -d XXXXXXXXXX --suffix=-incoming)
$ ls -1

Configure tftpd-hpa to allow creation of new files. Simply add –create to TFTP_OPTIONS in /etc/default/tftpd-hpa.

# /etc/default/tftpd-hpa

TFTP_OPTIONS="--secure --create"

And lastly restart tftpd-hpa.

$ sudo /etc/init.d/tftpd-hpa restart
[ ok ] Restarting tftpd-hpa (via systemctl): tftpd-hpa.service.

Step 3: Firewall rules

If you have a software firewall enabled you’ll need to allow access to port 69/udp. Either add this rule to your firewall scripts if you manually configure iptables or run the following UFW command:

$ sudo ufw allow tftp

Step 4: Transfer files

Before doing a firmware upgrade or other possibly destructive maintenance I always backup my switch config and firmware.

cisco-switch#copy running-config tftp://
Address or name of remote host []? 
Destination filename [UHiI443eTG-incoming/config-cisco-switch]? 
3554 bytes copied in 0.388 secs (9160 bytes/sec)
cisco-switch#copy flash:?
flash:c1900-universalk9-mz.SPA.156-3.M2.bin flash:ccpexp flash:cpconfig-19xx.cfg flash:home.shtml

cisco-switch#copy flash:c1900-universalk9-mz.SPA.156-3.M2.bin tftp:// 
Address or name of remote host []? 
Destination filename [UHiI443eTG-incoming/c1900-universalk9-mz.SPA.156-3.M2.bin]? 
85258084 bytes copied in 172.692 secs (493700 bytes/sec)

Files in incoming will be owned by tftp mode 666 (world writable) by default. Remember to move those files to your outgoing directory and change ownership to root mode 644 for safe keeping.

Once you’re sure your switch config and firmware is safely backed up it’s safe to copy new firmware to flash or do any other required destructive maintenance.

Step 5: Prevent TFTP access

It’s good practice on a notebook to deny services when not actively in-use. Assuming you have a software firewall be sure to deny access to your TFTP server when on the road or when connected to hostile networks.

$ sudo ufw deny tftp
Rule updated
Rule updated (v6)
$ sudo ufw status
Status: active

To Action From
-- ------ ----
CUPS ALLOW Anywhere 
OpenSSH DENY Anywhere 
69/udp DENY Anywhere 
CUPS (v6) ALLOW Anywhere (v6) 
OpenSSH (v6) DENY Anywhere (v6) 
69/udp (v6) DENY Anywhere (v6)

Read more

Managing multiple facilities across multiple continents can be a pain especially when Wi-Fi is involved. Different regions use different frequencies depending on regulatory domain. And, depending on your hardware vendor, compliant hardware could be backordered.

In my case, the Cisco Aironet 1140 Series Access Point (AIR-AP1142N-T-K9 802.11a/g/n Standalone AP; Int Ant; Taiwan C) is backordered by 4-6 weeks. I guess our Taipei 101 office is out of luck for a while unless I can find a different piece of compliant hardware.

Here are some miscellaneous regulatory notes for when I need to revisit this in the future:

Read more

For you mobile geeks out there HP Home currently has 3-cell batteries for the HP Mini 1000 and 110 on sale for 60% off as well as a $15-off coupon you can use (ACY93421). No idea how long this is going to last.

The 6-cell batteries are regular price but the coupon should also work.

Photo credit: / CC BY-NC-SA 2.0

Read more

If you have a mixed bag of Polycom kit in your office, be sure to check out the VoIP SIP Software Release Matrix to check on compatible versions. In our case, I chose SIP version 3.1.3RevC since it’s compatible with both the IP 430 and the IP 4000. I’ll probably bump up to SIP version 3.2.0 for the IP 430; just not today.

Also pay special attention to the release notes. Just because a Firmware version is on the download page for a particular model doesn’t mean it will work. We had to mix and match with Firmware version 4.1.3 for the IP 4000 and 4.2.0 for the IP 430. This is difficult (but not impossible) since pre-4.0 Firmware versions look for bootrom.ld instead of modelnumber.bootrom.ld in 4.0 and higher versions.

The solution was simple; I dropped the following files into place:

  • IP 430 4.2.0 Bootrom (Split) 2345-11402-001.bootrom.ld
  • IP 430 3.1.3RevC SIP (Split) 2345-11402-001.sip.ld
  • IP 4000 4.1.3 Bootrom (Split) 2201-06642-001.bootrom.ld
  • IP 4000 3.1.3RevC SIP (Split) 2201-06642-001.sip.ld
  • Generic 4.1.3 Bootrom (Combined) bootrom.ld

This way both the IP 430 and the IP 4000 will properly flash themselves with the 4.1.3 Combined image, then the IP 430 will step up to the 4.2.0 Split image on its next reboot.

For even more fun, the new macaddress.cfg files support per-model config files, so I also created phone1-3.1.3C.cfg and sip-3.1.3C.cfg to selectively upgrade a few phones for testing.

Oh, and remember to move bootrom.ld out of the way if you only want to test upgrade a few phones you’ve pre-modified config files for. You really don’t want to brick your whole office, do you?

Read more

The aging Red Hat Enterprise ES4 server I have colocated at ServerBeach was starting to get a bit crufty and I felt kind of dirty running RHEL instead of Ubuntu now that I’m working for Canonical. It was finally time to bring up a shiny new Dell PowerEdge 440 running Ubuntu 8.04 LTS Hardy Heron however ServerBeach does not yet officially support Ubuntu and will not do custom OS loads.

No problem. ServerBeach provides a brilliant tool called RapidRescue that allows you to reboot your server into a Linux recovery session and gives remote console access to the disks and hardware. I whipped together an awful hack to take advantage of this tool and automate the process of formatting the hard drives and debootstrapping an Ubuntu install. Not exactly elegant, but it gets the job done. </p>
            <a href=Read more


MS-DOS or another DOS derivative is still required for flashing the BIOS on some desktops, servers, notebooks, and mobile devices. These tools automate the creation of boot floppies and USB thumbdrives instead of fighting with tools like MKBT (Make Bootable).

Required Tools


  • Windows is required to run both installers. I have not tested under Wine or emulation.
  • The unofficial MS-DOS 6.22 boot floppy comes from and not from Microsoft.
  • The official Dell 32 Bit Diagnostics utility comes directly from Dell but AUTOEXEC.BAT must be modified for use on a non-Dell system. The info page for version CW1337A0 is available from Dell Support and additional versions are available directly from the Dell Diagnostics Repository.
  • Some prototype netbooks and MID devices refuse to boot MS-DOS. You’re on your own.
  • These tools are not licensed for redistribution.
  • These tools will erase the destination floppy disk or USB thumbdrive before creating bootable media.

MS-DOS 6.22 boot floppy

  1. Attach a USB floppy drive and execute BOOT622.EXE.
  2. Follow the on-screen instructions to write image to the floppy disk.
  3. Remove unneeded files to free up space and copy your custom BIOS image and BIOS flash utilities to the floppy disk.
  4. Upon booting, the floppy disk will be drive A:.

Dell 32 Bit Diagnostics

  1. Execute CW1337A0.EXE to extract archive contents to a folder.
  2. Execute DDDP.EXE and insert a USB thumbdrive.
  3. Select Install to a USB Flash Drive.
  4. Select the USB Flash Drive to use and click OK.
  5. If the USB thumbdrive is too large then a warning will be displayed regarding the maximum size of FAT 16 partitions; click Yes to continue.
  6. Click OK when complete then select Finished Creating Diagnostic Media.
  7. Modify AUTOEXEC.BAT on the newly-created USB thumbdrive and REM out or delete the DELLDIAG.COM and REBOOT.COM lines at the end of the script. DELLDIAG.COM will only run on approved Dell systems so by default the tool will give an error, exit, and reboot non-Dell systems.
  8. Copy your custom BIOS image and BIOS flash utilities to the USB thumbdrive.
  9. Upon booting, the USB thumbdrive will be drive C: and the Dell 32 Bit Diagnostics RAMDISK will be drive D:.

Booting Devices

Booting your device should be as simple as simple as Plug and Play; make sure the boot order is configured to see the USB thumbdrive, USB floppy disk, or internal floppy disk before the hard drive. Once MS-DOS loads follow the instructions that came with your BIOS image or BIOS flash utility.

Read more