Bug 447135 - the default directory for tftd is not /tftpboot anymore
the default directory for tftd is not /tftpboot anymore
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: tftp (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Martin Nagy
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-18 02:28 EDT by dann
Modified: 2016-07-26 19:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-02 02:40:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dann 2008-05-18 02:28:51 EDT
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:
Comment 1 Fedora Update System 2008-05-20 06:34:48 EDT
tftp-0.48-4.fc9 has been submitted as an update for Fedora 9
Comment 2 Martin Nagy 2008-05-20 06:35:41 EDT
Fixed by adding a symlink.
Fixed in: tftp-0.48-4.fc10 and tftp-0.48-4.fc9
Comment 3 Fedora Update System 2008-05-21 07:09:04 EDT
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.
Comment 4 Warren Togami 2008-05-21 14:22:31 EDT
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.
Comment 5 Warren Togami 2008-05-21 14:52:31 EDT
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.
Comment 6 Warren Togami 2008-05-21 15:31:28 EDT
I am pushing -6 now because we need an update to undo the damage of -4.  -6 is
identical to -3.
 
Comment 7 Fedora Update System 2008-05-21 19:25:07 EDT
tftp-0.48-6.fc9 has been submitted as an update for Fedora 9
Comment 8 Axel Thimm 2008-05-22 11:32:31 EDT
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)
Comment 9 dann 2008-05-22 11:48:32 EDT
(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.

Comment 10 Fedora Update System 2008-05-28 22:33:56 EDT
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.
Comment 11 Michael DeHaan 2008-05-29 11:37:36 EDT
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



Comment 12 dann 2008-05-29 12:21:15 EDT
(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?
Comment 13 Michael DeHaan 2008-05-29 12:33:25 EDT
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.




 
Comment 14 dann 2008-05-29 13:25:38 EDT
(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.
Comment 15 Michael DeHaan 2008-05-29 13:59:18 EDT
>> 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.


Comment 16 Martin Nagy 2008-05-30 07:54:49 EDT
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.
Comment 17 dann 2008-05-30 10:07:26 EDT
(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".
Comment 18 Martin Nagy 2008-05-30 10:47:55 EDT
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.
Comment 19 dann 2008-05-30 11:27:31 EDT
(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...
Comment 20 Michael DeHaan 2008-05-30 11:35:06 EDT
" 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.



Comment 21 dann 2008-05-30 11:50:07 EDT
(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."
Comment 22 Martin Nagy 2008-05-30 12:11:55 EDT
(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.
Comment 23 Martin Nagy 2008-05-30 12:25:00 EDT
BTW, here:
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00937.html
This thread discussed the movement some time ago.
Comment 24 Michael DeHaan 2008-05-30 12:29:09 EDT
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 :)

Comment 25 Martin Nagy 2008-06-02 02:40:25 EDT
Closing this bug as WONTFIX. If there are still some concerns, feel free to
reopen this again. Thanks.

Note You need to log in before you can comment on or make changes to this bug.