Bug 143536
| Summary: | tftp-server rejects valid /etc/tftpd/rules format | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Clark Williams <williams> |
| Component: | tftp | Assignee: | Radek Vokál <rvokal> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | joshuadfranklin, k.georgiou, mattdm, mshuler |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | RHEL3U7NAK | ||
| Fixed In Version: | RHBA-2006-0312 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-07-20 14:37:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 181405 | ||
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 quickly... QA? 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? Sincerely, Concerned, upset admin for a supposed Enterprise-Level OS, with consistantly broken services, from supposedly QA'ed software updates over the last year. Hello, 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? Kind Regards, Michael Shuler 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? Kind Regards, Michael Shuler 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! http://syslinux.zytor.com/archives/2004-September/004036.html The FC4 tftp-server-0.40-6.i386.rpm binary works fine on RHEL4. Hello Radek, 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 be resolved? Thanks, Michael 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. http://rhn.redhat.com/errata/RHBA-2006-0312.html Internal Status set to 'Resolved' Status set to: Closed by Tech Resolution set to: 'Auto Closed' This event sent from IssueTracker by pdemauro issue 73224 |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 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[8294]: r rules cannot be inverted, line 1: ^[^/] /tftpboot/\0 # Convert non-absolute files Version-Release number of selected component (if applicable): tftp-server-0.39-0.EL3.1 How reproducible: Always Steps to Reproduce: 1. insure that /etc/tftpd/rules exists and contains the above rule 2. modify the /etc/xinetd.d/tftp file contains: service tftp { 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. Additional info: 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?