On Thu, May 21, 2015 at 11:23:28PM +0200, Norbert Lange wrote: > 2015-05-21 16:59 GMT+02:00 Ron <r...@debian.org>: > > > > Hi Norbert, > > > > On Thu, May 21, 2015 at 10:25:38AM +0200, Norbert Lange wrote: > >> Hello, > >> > >> since this behaviour is still on Jessie and is rather inconvenient. > >> Whats the recommended workaround nowadays? > > > > Can you elaborate a little more on exactly what configuration you have > > with Jessie that you see this happening on? > > (ie. what init system, what brings up you network(s) etc.) > > Bog standard Jessie x86_64 Gnome3-Desktop. > Systemd and Networkmanager I guess, the point is that installing > tftpd-hpa doesnt work out-of-the-box
Well it's been working out of the box for me, and apparently for almost everybody else too - and the problem with systemd was supposed to have been solved by its maintainers before the release - so the details of exactly why you got hit by it were kind of pertinent here ... >From a sample space of two, Networkmanager appears to be emerging as the common culprit ... > >> I want to serve on 2 networks, so setting my ip address wont cut it. > > > > I have this serving on 4 networks with an address set, so that alone > > isn't a problem. What's the situation in your case that it won't? > > Networks as in 2 separate network interfaces with 2 separate IPs, > one is a local 192.168.x.x network at my desk and the other a > bigger 10.x.x.x network. Yes, I mean 4 networks as in separate network interfaces with 4 separate IPs, with the one tftpd instance serving all of them. That part isn't the problem here. > Id bet some real money that the primary use for tftp is that its run > on some servers, not having a laptop and identifying your > home/internal network by the ip address you got assigned. > Thats the usecase you are talking about? I'm running this on a "Real Server", yes - which also means no Gnome desktop and no NM - but the only person who had or reported the same problem as you have was running this on a laptop ... Which surprised me a little too, but appears to be a real and valid use case as it was described. > Just wondering about the reasoning here, I would `ve never thought > someone would "secure" > his important data on a "trivial" ftp server by expecting you get a > different IP than at home in > wireless networks (nevertheless someone malevolently giving your > laptop the special IP via DHCP) > To each his own and its nice its working for you, but I really cant > follow the arguments (), > but then I dont know everything about the involved network stacks. I'm not following what you're trying to say there either, or where you got that line of thinking from, so I can only sympathise if you're confused by it :) > I will just state the issue more clearly and what I expect. > > Problem: I want to host a tftp for fetching firmwares via a bootloader. Network booting is what I understand most people want this for, yes. It's all I use it for. It's not really the right tool for much else. > I have two network interface where I want the files accessible. > Securing the tftp doesnt matter for me (if, then Id prefer locking to > interfaces), And that's exactly what the default configuration gives most people, with the debconf prompt letting you set the address(es) it will bind to explicitly if you want something different to that. > I want a painless and easy setup, ideally for providing the company with > simple > steps to reproduce (apt-get install tftpd-hpa; echo done) Which is exactly what the default of INADDR_ANY was originally intended to do. It's a little dated, showing its age from the era before tftpd supported IPv6, but IPv6 support isn't your problem here either. > State: We are using Wheezy and I added an if-up hook (which I consider > a mean hack). > Sometime we will change to Jessie, means I tested an untouched > installation and wrote down the steps necessary. > > Issue: tftpd service will fail when booting (as in the service is > stopped), supposedly because > the network interface(s) arent up. Which appears to be an issue with Networkmanager ... The ifupdown support for both sysvinit and systemd should not have this problem, and lots of things other than this will indeed fail to bind to their listening addresses if those interfaces are not present and configured on the system. > Workarounds: > 1) manually restarting the service later will fix this issue. > 2) changing TFTP_ADDRESS=":69" will fix the issue. > 3) applying my patch and omitting the --address option works too Which are all basically just hacks around the problem of having booted your system with a non-functional network. Which appears to be a problem that people using Networkmanager have. I don't know what its proposed solution to that is, but if it doesn't have one, then it's not really suitable for use on servers. > I strongly believe it doesnt matter when you un/replug the wire after > tftpd was successfully started but I would have to test this "the wire" doesn't have anything to do with this. Networkmanager not configuring your network before services that want to use it start is the problem you appear to be are having. > >> Is changing to TFTP_ADDRESS=":69" cause any issues, or a if-up.d > >> script still the best option? > > > > As we discussed earlier in this bug, if that's what you *want* it > > is fine, but if there is some other bug that is still causing this > > problem, that won't help people who do want or need to restrict > > this to just a subset of the available network addresses - so we > > probably need to identify the real bug that you've hit so that we > > can fix it for them too. > > > > (which is an independent question from your patch to allow running > > this with just the tftpd default options for people who choose that > > too, which seems like it's probably a reasonable idea as well). > > So In short, hope you dont take any offense but to me its clear that > TFTP_ADDRESS="0.0.0.0:69" should mean the same as TFTP_ADDRESS=":69" > should mean use any IP. I don't see why you worry that might offend me, but if that's "clear" to you, then you probably need to take a closer look at what 0.0.0.0 aka INADDR_ANY actually means as a listening socket address :) In the world where IPv6 exists, those two are very much not the same. > Conversely if we ignore common socket rules, > and TFTP_ADDRESS="0.0.0.0:69" would mean bind to one fixed IP "0.0.0.0" > then the defaults would need to be adjusted. I don't know what you mean by "common socket rules", but 0.0.0.0 has a very specific and well defined meaning. > Under this perspective I don`t understand many of the arguments above And I still don't know exactly which "arguments" you're referring to here. AFAICS we have an open question about what the best default tftpd configuration should be, partly because it now supports IPv6, and partly because the world is a different place to what it was when this was first picked and perhaps we ought to be a little more defensive by default - but there's already a debconf prompt that lets you pick that for yourself anyway, so this is 'important' but not urgent. And then there is a problem, which is by no means specific to tftpd, which appears to essentially be a Networkmanager design and/or configuration flaw. The only thing that is certain about the first question, is whatever we choose it shouldn't be on the basis of hiding Networkmanager bugs. How you hack around those locally if you insist on using it is up to you, but we can't "fix" those in this software, short of rewriting parts of it to listen to netlink events for dynamic interface creation. ... which probably isn't really a very high priority for Server Use. That's much more of a laptop problem. I'm a bit confused about what you're aiming for here, because you're "betting" this software is for server use, but seem confused about why it doesn't work so well in its current default configuration if you use laptop tools to configure your network. Yes, you can configure a hack around that in some of the software it causes problem with - but that's a different question to what is actually the best default for *this* package to ship with in a hands-off install. I'm pretty sure we don't ever want to omit the --user option and have this run as 'nobody', but not supplying --address might have some use or merit. It's less clear cut if that should be the default though, or if it's functionally different in any significant way to what is already possible ... Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
