From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
TFTP server rejects the following rule:
r ^[^/] /tftpboot/\0 # Convert non-absolute files
with the syslog message:
Dec 21 10:50:14 barn in.tftpd: r rules cannot be inverted, line
1: ^[^/] /tftpboot/\0 # Convert non-absolute files
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. insure that /etc/tftpd/rules exists and contains the above rule
2. modify the /etc/xinetd.d/tftp file contains:
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot -m /etc/tftpd/rules -v
disable = no
per_source = 11
cps = 100 2
flags = IPv4
3. restart the xinetd service
4. put a file in /tftpboot on the server (e.g. /tftpboot/foo)
5. from another system, attempt to tftp the file from the server:
$ tftp testserver
tftp> get foo
Actual Results: TFTP operation failed, syslog contained message from
in.tftpd that 'r rules cannot be inverted
Expected Results: The file should have been transferred.
Yes, I realize the rule that's listed is a nop when you chroot to
/tftpboot, but the point is that a valid rule (one that is listed in
the source sample.rules file and worked in the previous version)
causes tftpd to fail in mysterious ways.
Since the listed negation character is a '~' and there is no '~' in
the failing rules file and since there is only one spot in the source
where syslog talks about 'r rules cannot be inverted', I would suspect
some sort of initialization bug?
I'm getting the same error message with this rule too:
rg \\ /
This is already fixed in FC3 tftp-server-0.40. I've backported the
patch into tftp-server-0.39-0.EL3.2 for RHEL3.
And 0.39-0.EL3.2 will be released when, or is currently available
where? RedHat introduced an flaw, which should be corrected
And the QA between 2004-10-19 and 2004-12-21 of the U4 released
0.39-0.EL3.1 package, as mentioned in #131736 was where?
Concerned, upset admin for a supposed Enterprise-Level OS, with
consistantly broken services, from supposedly QA'ed software updates
over the last year.
U5 was released on 5/18, and a mass of subsequent package updates on 5/19, and
tftp/tftp-server was not included, as I was hoping.
Could there, please, be an update posted on the progress of this bug, as well as
the possibility of pushing this as errata, and not waiting another 3-4 months
for a fix?
What is going on with this bug?
This one is a serious problem that breaks network installation servers.
Radek, could this, please, be updated with a target package release date?
The fixed package is proposed for RHEL3-U7
Also worth noting re comment #3 that there is no tftp-server-0.40 package in FC3
nor in FC3 updates.
This also effects RHEL4. This bug was fixed in tftp-server in September 2004!
The FC4 tftp-server-0.40-6.i386.rpm binary works fine on RHEL4.
It appears that from the U7 beta package listing that an update will not be
released this quarter. Could you please confirm, as well as post when this will
This issue is on Red Hat Engineering's list of planned work items
for the upcoming Red Hat Enterprise Linux 3.8 release. Engineering
resources have been assigned and barring unforeseen circumstances, Red
Hat intends to include this item in the 3.8 release.
How about RHEL4? It's still at 0.39.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
Internal Status set to 'Resolved'
Status set to: Closed by Tech
Resolution set to: 'Auto Closed'
This event sent from IssueTracker by pdemauro