While upgrading the firmware on several network devices this past weekend, I needed to bring up a tftp server so the clients could retrieve the firmware image. I had a Fedora host readily available, so getting tftp up and working was super easy. Before configuring the server, I ran yum to install the tftp-server package:
$ yum install tftp-server
Loaded plugins: refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package tftp-server.x86_64 0:0.49-3.fc11 set to be updated
--> Processing Dependency: xinetd for package: tftp-server-0.49-3.fc11.x86_64
--> Running transaction check
---> Package xinetd.x86_64 2:2.3.14-22.fc11 set to be updated
--> Finished Dependency Resolution
........
Once the package was installed, I set “disable” to no in /etc/xinetd.d/tftp (I also disabled the server as soon as I was done using it):
$ cat /etc/xinetd.d/tftp
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /var/lib/tftpboot
disable = no
per_source = 11
cps = 100 2
flags = IPv4
}
After the server was configured, I restarted xinetd and everything worked like a champ. If you encounter any issues tftp’ing files, there are a couple of things you can do to troubleshoot the source of the problem:
While tftp is completely insecure, it’s still one of those protocols that we have to live with.
I’ve really like how yum has the “whatprovides” keyword. You can execute
$ yum whatprovides startkde
And yum will search all of the known packages within the installed repositories and return back the package you need to install in order to have the “startkde” binary. At that point, all thats needed is a
$ yum install <package>
But how do we do this on Ubuntu and other Linuxes which have apt-get and aptitude?
I found that this same functionality can be searched using the “apt-files” package. So first, lets install apt-files.
$ apt-get install apt-file
Once apt-file has been installed, we need to update its cache.
$ apt-file update
Then, just search for the file you’re looking for. Here, I’m looking for startkde which is provided by the kde-workspace-bin dpkg.
$ apt-file search startkde
kdebase-workspace-bin: /usr/bin/safestartkde
kdebase-workspace-bin: /usr/bin/startkde
kdebase-workspace-bin: /usr/share/man/man1/startkde.1.gz
So, once I know the package name, its just a quick apt-get install and i’m golden.
$ apt-get -y install kdebase-workspace-bin
$ which startkde
/usr/bin/startkde
Nice! Keep in mind that the cache is stored on the local file system, so updating the cache before issuing a search is always a good idea.
I was doing some research tonight, and needed to look inside my initrd image to see if a couple of device drivers were present. Initrd images are stored as compressed cpio archives, which allows a pipeline like the following to be used to extract the contents of an image:
$ gunzip < initrd-2.6.29.4-167.fc11.x86_64.img | cpio -i --make-directories
14050 blocks
Once extracted, you can use cd and cat to view the files and directories that are part of the image:
$ ls -l
drwxrwxrwt. 11 root root 4096 2009-07-14 23:30 .
drwxr-xr-x. 23 root root 4096 2009-07-07 14:55 ..
drwx------ 2 root root 4096 2009-07-14 23:30 bin
drwx------ 3 root root 4096 2009-07-14 23:30 dev
drwx------ 4 root root 4096 2009-07-14 23:30 etc
-rwx------ 1 root root 1938 2009-07-14 23:30 init
-rw------- 1 root root 3428816 2009-07-14 23:29 initrd-2.6.29.4-167.fc11.x86_64.img
drwx------ 6 root root 4096 2009-07-14 23:30 lib
drwx------ 2 root root 4096 2009-07-14 23:30 lib64
drwx------ 2 root root 4096 2009-07-14 23:30 proc
lrwxrwxrwx 1 root root 3 2009-07-14 23:30 sbin -> bin
drwx------ 2 root root 4096 2009-07-14 23:30 sys
drwx------ 2 root root 4096 2009-07-14 23:30 sysroot
drwx------ 4 root root 4096 2009-07-14 23:30 usr
$ ls -l etc
total 20
-rw-r--r-- 1 root root 29 2009-07-14 23:30 fedora-release
-rw-r--r-- 1 root root 1976 2009-07-14 23:30 ld.so.cache
-rw-r--r-- 1 root root 28 2009-07-14 23:30 ld.so.conf
drwx------ 2 root root 4096 2009-07-14 23:30 ld.so.conf.d
drwx------ 2 root root 4096 2009-07-14 23:30 sysconfig
lrwxrwxrwx 1 root root 14 2009-07-14 23:30 system-release -> fedora-release
Like most DHCP implementations, the ISC DHCP server supports sending host names in response to a DHCP DISCOVERY message. The host name is sent when DHCP option 12 is requested by the client, and the name is derived from one of two locations:
To configure ISC DHCP to set the host-name option based on DNS data, you can set the “get-lease-hostnames” directive to true:
get-lease-hostnames true;
If you are unable to use DNS to derive the host name, you are still in luck. You can specify the name to assign to the client in a host block:
host thecrue {
hardware ethernet 00:24:8c:4e:07:f6;
fixed-address thecrue.prefetch.net";
host-name "thecrue.prefetch.net"
}
In the example above, the host name “thecrue.prefetch.net” will be assigned to the client with mac address 00:24:8c:4e:07:f6. If you have a large number of hosts and you want to use the name that is attached to the host directive, you can use the “use-host-decl-names” directive. Here is an example that enables the directive, and defines two hosts that will get their host name from the entry attached to the host directive:
group {
use-host-decl-names on;
host thecrue {
hardware ethernet 00:24:8c:4e:07:f6;
fixed-address thecrue.prefetch.net";
}
host aic {
hardware ethernet 00:24:8c:4e:07:f7;
fixed-address aic.prefetch.net";
}
}
There a couple of additional options that are useful for integrating ISC DHCP with DNS, but I’ll save those for a future post.
I attempted to upgrade my ISC DHCP installation to dhcp-4.1.1b1 this past weekend, and ran into the following configure error:
$ ./configure --prefix=/bits/software/dhcp-4.1.1b1
checking for a BSD-compatible install... /bin/ginstall -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... no
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... unsupported
checking for style of include used by make... none
checking dependency style of gcc... none
checking how to run the C preprocessor... /lib/cpp
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.
Th config.log had a number of errors similar to the following:
conftest.c:11:19: stdio.h: No such file or directory
conftest.c:12:23: sys/types.h: No such file or directory
conftest.c:13:22: sys/stat.h: No such file or directory
Which are due to missing system headers. I reviewed the list of packages that were installed, and sure enough SUNWhea (this package contains the various header files) was missing. I installed this package as well as a number of others:
$ pkgadd -d . SUNWhea SUNWbinutils SUNWarc SUNWgcc SUNWgccruntime
$ pkgadd -d . SUNWlibsigsegv SUNWgm4 SUNWgnu-automake-110 SUNWaconf
Any everything compiled and installed perfectly.