+++ This bug was initially created as a clone of Bug #218998 +++
Description of problem:
By default rarpd will not answer a request if a boot image for the requesting
client is not found in the /tftpboot. I use rarpd only to answer requests
for Sun T3s and 3510FC devices that have no use for a boot image.
To get around this one must pass a -e to the daemon.
-e Skip the check for bootable image in the TFTP boot directory. If
not present, then even if the Ethernet address is present in the
ethers database but the bootable image for the resolved IP does
not exist, rarpd will not respond to the request.
It would be nice if you could modify the init script as follows:
[root@noc init.d]# diff -u rarpd.orig rarpd
--- rarpd.orig 2006-02-12 01:06:26.000000000 -0800
+++ rarpd 2006-11-30 17:36:08.000000000 -0800
@@ -11,6 +11,10 @@
# Source function library.
+if [ -f /etc/sysconfig/rarpd ]; then
+ . /etc/sysconfig/rarpd
test -x /usr/sbin/rarpd -a -f /etc/ethers || exit 0
@@ -20,7 +24,7 @@
# Check if rarpd is already running
if [ ! -f /var/lock/subsys/rarpd ]; then
echo -n $"Starting $prog: "
- daemon /usr/sbin/rarpd
+ daemon /usr/sbin/rarpd $OPTIONS $INTERFACE
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/rarpd
[root@noc init.d]# cat /etc/sysconfig/rarpd
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. service start rarpd
No means to configure options.
Tweakage of sysconfig file. Options are:
rarpd [ -dveaA ] [ -b tftpdir ] [ interface]
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
I'm not sure what the problem is here. I'll open a support case for this, but
there's a patch here - the Fedora version of this bug is already long fixed, and
this is a minimal impact change - it simply adds functionality that should
already be there.
If someone could appeal the RHEL 4.7 decision, and propose for RHEL 4.8, I would
be eternally grateful.