Description of problem: The default directory for tftpd has been /tftpboot for ever, it has now been changed to /var/lib/tftpboot A lot of scripts depend on that directory being there. This is especially important for embedded systems development which use tftd a lot. RHEL still uses /tftpboot, so this will force special casing in many scripts, or people will have to edit /etc/xinetd.d/tftp. Please, at least provide a symlink, otherwise this will cause a lot of pain for absolutely no gain. Version-Release number of selected component (if applicable): tftp-server-0.48-3.fc9.i386 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
tftp-0.48-4.fc9 has been submitted as an update for Fedora 9
Fixed by adding a symlink. Fixed in: tftp-0.48-4.fc10 and tftp-0.48-4.fc9
tftp-0.48-4.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
Sorry, tftp-0.48-4.fc9 and -5 have been retracted as an update because it they are problematic and wrong. Here's what happened: 1) https://fedorahosted.org/cobbler/ticket/62 Prior to Fedora 9 there was agreement between me and Michael Dehaan to move the default tftp directory to /var/lib/tftpboot because it is LSB compliant and it matches Debian. 2) We were aware that this would upset some people because the old location was used for many years. 3) We also decided that it would be too problematic and wrong to attempt any auto-migration or compat symlink. The problems of -4 demonstrate this to be true. You simply cannot make a packaged symlink out of a directory that contains files. The scriptlet in -5 is also wrong in several ways. I realize that this decision has created short-term inconvenience. More software must be updated to handle the new standard tftpboot directory.
Let me further clarify. We decided to do no symlink and no auto-migration because of three key problems: 1) You cannot have a symlink if you don't forcefully migrate everything that was previously in /tftpboot. 2) Auto-migration be extremely messy and error prone. 3) How long do you keep the /tftpboot compat symlink in the distro? Forever? The current implementation in -5 naively creates a symlink only if /tftpboot doesn't exist. This is wrong because it creates an inconsistent situation where /tftpboot could be invalid (an old directory) or valid (symlink pointing at the new location). This is not completely ruling out the possibility of fixing #1 and #2. We could discuss this problem more and consider proposed implementations. But understand the reasons why we didn't already do it before F9, and it is especially RISKY to make this kind of change after a release as -4 demonstrated. https://admin.fedoraproject.org/updates/F9/FEDORA-2008-4286 I am especially not pleased that -4.fc9 went into updates stable without a testing period and feedback in the update ticket.
I am pushing -6 now because we need an update to undo the damage of -4. -6 is identical to -3.
tftp-0.48-6.fc9 has been submitted as an update for Fedora 9
system-config-netboot-cmd currently owns files under /tftpboot. Therefore it needs to be fixed as well and released into updates together with the fixed tftp-server. (perhaps there are other packages owning parts under /tftpboot, so they would need to be taken into consideration as well)
(In reply to comment #8) > system-config-netboot-cmd currently owns files under /tftpboot. Therefore it > needs to be fixed as well and released into updates together with the fixed > tftp-server. > > (perhaps there are other packages owning parts under /tftpboot, so they would > need to be taken into consideration as well) Perhaps the decision to move /tftpboot should be seriously reconsidered then. There are many scripts/makefiles in use that compile SW and put it in /tftpboot, documentation, training manuals telling people to put their stuff in there. Please find someone that uses /tftpboot on a daily basis and ask what are the implications of changing the default directory, especially when dealing with a mixed environment, with different machines running different distributions.
tftp-0.48-6.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
Packages that own things under tftpboot realy should not. What should happen is that they, if needed, should create directories under them when needed. Currently Cobbler 1.0 (pushed to mirrors already) is smart enough to read the xinet.d config for tftp and knows which directories to write files in. I just found out that I still have the directory owned in the specfile and will be removing that in the next build. For applications already out there, or reference books, etc, that mention /tftpboot, those applications still work absolutely fine as long as the config file for tftp still points to /tftpboot. If things break, it can be moved back. For upgrades, the path will still be /tftpboot. For old OS's, also /tftpboot, so I think the only things that are broken are new installs of old tools on F9. If you are still using system-config-netboot, please *STOP*. This tool is unmaintained and is only included for legacy reasons. There are lots of things it does not check for on setup, and is rather error prone. Cobbler (http://cobbler.et.redhat.com) is the future of that tool, and if there are things you don't like in Cobbler, please report them to me and we'll get them resolved for you. What other applications in Fedora own files under /tftpboot? You can point them to me and I help share how they need to be fixed. Even if unfixed though, the process of getting them to run is as simple as changing the config file for tftp in xinetd.d
(In reply to comment #11) > For applications already out there, or reference books, etc, that mention > /tftpboot, those applications still work absolutely fine as long as the config > file for tftp still points to /tftpboot. If things break, it can be moved > back. For upgrades, the path will still be /tftpboot. For old OS's, also > /tftpboot, so I think the only things that are broken are new installs of old > tools on F9. That's exactly the point, now people need to either edit /etc/xinet.d/tftp or change their scripts. If you work in a multi-platform environment, then editing /etc/xinet.d/tftp. But this just creates extra work for ZERO benefit. > If you are still using system-config-netboot, please *STOP*. Nobody said anything about that. > What other applications in Fedora own files under /tftpboot? You can point them > to me and I help share how they need to be fixed. Even if unfixed though, the > process of getting them to run is as simple as changing the config file for tftp > in xinetd.d It's not about Fedora, which is just a small piece of the SW puzzle anyway. For embedded sw development, tftp is very convenient you can compile and restart the device and download the new version of your program. Scripts and makefiles have been putting stuff in /tftboot for a very long time, and engineers are trained to look there. What are the benefits of changing this?
The benefits are of LSB compliance. (A), TFTP (as much as I love it) should not be special and get to install itself in root when no other application does. (B) this is about making software work better with multiple distributions and having a more standardized filesystem. The pain of changing a configuration file is relatively minimal, especially if you are using something like cfengine or puppet. The scripts that still reference /tftpboot in a hard coded fashion DO need to be changed. "It's not about Fedora, which is just a small piece of the SW puzzle anyway." Absolutely right, which is why we are changing this. Admittedly, I made many of the arguments you first made when I was approached with this suggestion, though ultimately since it just comes down to moving a config file and no existing scripts have to be broken, this is not an intrusive change. "Scripts and makefiles have been putting stuff in /tftboot for a very long time, and engineers are trained to look there." This argument can generally be used as a reason to not change /anything/. I'm not sure I still want drum cylinders and punchcards :) We have to move forward with fedora and there are advantages for making it easier for upstream applications to target multiple distributions. Debian, for instance, is already using /var/lib/tftpboot.
(In reply to comment #13) > The benefits are of LSB compliance. Which from a user point of view is not a benefit, and even people inside Redhat don't seem to think that LSB is such a great thing. > (B) this is about making software work better with multiple distributions and > having a more standardized filesystem. Which is exactly the opposite of what happens now: if one uses RHEL4, or 5 and F9 things are different... > The scripts that still reference /tftpboot in a hard coded fashion DO need to be > changed. Which is exactly the biggest problem pointed out from the beginning. If you have machines that use RHEL and F9 what do you do? Yet more hacking involved. > "Scripts and makefiles > have been putting stuff in /tftboot for a very long time, and engineers are > trained to look there." > > This argument can generally be used as a reason to not change /anything/. I'm > not sure I still want drum cylinders and punchcards :) That does not follow. People are happy to change if the change brings some visible benefit. That is not the case here.
>> That does not follow. People are happy to change if the change brings some visible benefit. That is not the case here. It brings some benefits to management applications, though those benefits may not be readily apparent to you. Even so, since this is STILL controllable by a config file, this is essentially a debate about the value in the config file and is of little importance seeing it is so easily replaceable in kickstart %post, through config management, or by hand, depending on scale. If your application is properly coded to LOOK in the config file to see what the setting is (as Cobbler does), the demands on the user are zero. > If you have machines that use RHEL and F9 what do you do? Yet more hacking involved. Cobbler supports both in this fashion. The "hack" was not complex.
The change was already done, I don't think it's a good idea to reverse it now. I don't believe it's such a trouble to adjust the existing scripts and documentation, while it may take a while I still think it's worth it.
(In reply to comment #16) > The change was already done, I don't think it's a good idea to reverse it now. I > don't believe it's such a trouble to adjust the existing scripts and > documentation, while it may take a while I still think it's worth it. This is very disappointing, a user of this package says that this change is extremely inconvenient IN PRACTICE, and for many reasons, after all this dialog the only answer is: "it's not much trouble".
I am truly sorry for your trouble, but think about small and/or read-only root partitions for example. Please know that I am very upset that some people are unhappy because of a change. I assure you that I am not trying to dismiss the issue and ignore all the complaints. But ask yourself, if you'd be introducing the tftp package into a distribution, and would have to chose between /tftpboot and /var/lib/tftpboot, which one would you choose? I'd certainly went with /var/lib option, because I believe that is the right one. The tougher question is if you'd switch from bad option to good. I believe that this is what we do right now. I think that if we do it, we'll have some troubles at the beginning (and sadly, our users too) but then we'll just be on the good side "forever". The other option is to left everything as it is, and stay on the bad side ("forever" as well). I'm a kind of person that prefers to sacrifice the moment for the benefit of the future. I'm aware that it will cause trouble, but I still believe that they will pass in time. Could you at least provide some very concrete and realistic example of the kind of trouble this could cause you (or someone else) and the needed steps to fix them? Thanks.
(In reply to comment #18) > I am truly sorry for your trouble, but think about small and/or read-only root > partitions for example. Sorry, I don't have personal experience with those cases, so I can't provide a useful feedback for that case. > Please know that I am very upset that some people are > unhappy because of a change. I assure you that I am not trying to dismiss the > issue and ignore all the complaints. But ask yourself, if you'd be introducing > the tftp package into a distribution, and would have to chose between /tftpboot > and /var/lib/tftpboot, which one would you choose? I'd certainly went with > /var/lib option, because I believe that is the right one. If it was a new package, it wouldn't matter what the directory was, any default is just fine. But given that tftp is far away from being a new package, taking the discussion is this direction does not seem very productive. > The tougher question > is if you'd switch from bad option to good. I believe that this is what we do > right now. I think that if we do it, we'll have some troubles at the beginning > (and sadly, our users too) but then we'll just be on the good side "forever". > The other option is to left everything as it is, and stay on the bad side > ("forever" as well). I'm a kind of person that prefers to sacrifice the moment > for the benefit of the future. I'm aware that it will cause trouble, but I still > believe that they will pass in time. I disagree that any change is needed, or there's anything "bad" here... > Could you at least provide some very concrete and realistic example of the kind > of trouble this could cause you (or someone else) and the needed steps to fix > them? Thanks. I have many build scripts that use /tftpboot, many scripts/makefiles that run regressions that use /tftpboot. Instructions for users also specify /tftpboot. Many things need to be changed to support /var/lib/tftpboot. RHEL4 and 5 will still be in use for a long time, so supporting 2 locations will be needed for a while. The worst is the human factor: many people know about /tftpboot and will need to learn about a the new location. tftp is not something a lot of people know and care about, but for the ones that use it, it is crucial, and it is very important that it just works. Just my 2 cents...
" Instructions for users also specify /tftpboot. Many things need to be changed to support /var/lib/tftpboot. " If you would like to keep all of your applications working on F9, all you have to do is change your /etc/xinet.d/tftp on F9 to match the config you are using on your other operating systems. In fact, you should be able to copy the one from F8 right over.
(In reply to comment #20) > " Instructions for users also specify /tftpboot. > Many things need to be changed to support /var/lib/tftpboot. " > > If you would like to keep all of your applications working on F9, all you have > to do is change your /etc/xinet.d/tftp on F9 to match the config you are using > on your other operating systems. In fact, you should be able to copy the one > from F8 right over. First: please be careful when trimming citations, taking it out of context does not keep the original meaning, the main point is this: "The worst is the human factor: many people know about /tftpboot and will need to learn about a the new location."
(In reply to comment #19) > If it was a new package, it wouldn't matter what the directory was, any default > is just fine. But given that tftp is far away from being a new package, taking > the discussion is this direction does not seem very productive. It was a hypothetical question that I wanted answer for so I could go on with my second question. > I disagree that any change is needed, or there's anything "bad" here... I got my conclusion that there's something "bad" here from the previous question, but maybe you do not share my opinion. > I have many build scripts that use /tftpboot, many scripts/makefiles that run > regressions that use /tftpboot. Instructions for users also specify /tftpboot. > Many things need to be changed to support /var/lib/tftpboot. RHEL4 and 5 will > still be in use for a long time, so supporting 2 locations will be needed for a > while. But changing the locations even if they are hardcoded is not a problem, sed will suffice for that task. If you want backwards compatibility, then I am sorry, but we are not bound to provide it and I really think we should not. In RHEL4, you still need to use up2date instead of yum, this can also cause compatibility issues between RHEL4 and RHEL5 scripts. Also, you can always solve this by using in files, for example Makefile.in where you change every occurrence of /tftpboot to @tftpboot_path@ and then always just use sed to insert the appropriate value based on the OS you are using at the moment. I think this is a good solution in any case. > The worst is the human factor: many people know about /tftpboot and will need to > learn about a the new location. > tftp is not something a lot of people know and care about, but for the ones that > use it, it is crucial, and it is very important that it just works. Yes, I guess you are right. But this is just temporary and I'm sure everyone learns the new location quickly and there won't be any serious problems caused by this in the meantime. I'll try to fix up the documentation to help with this, but I think that for most people, rpm -ql tftp-server will suffice.
BTW, here: https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00937.html This thread discussed the movement some time ago.
You'll notice I was originally against this on that thread :) Warren made a very good persuasive argument at lunch about how we could make this work with only changing the config file, and the way that got implemented it really worked nicely. If your existing infrastructure doesn't want to deal with the possibility of multiple locations for /tftpboot, Cobbler does take care of this already :)
Closing this bug as WONTFIX. If there are still some concerns, feel free to reopen this again. Thanks.