Hi Ron 2015-05-22 2:08 GMT+02:00 Ron <r...@debian.org>: > 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 ...
Quite possibly its Networkmanager fault, but its strange that only tftp-hpa is affected. I also use fixed ip/dns via the gnome gui (what exactly the gui affects and how NM is hooked into it is unclear to me). At home I have two systems where I killed NM and used the interfaces config file, exactly because this thing caused me alot trouble already And I am far from the only one with the problem, I found this report from another sites. And Ubuntu has this issue too: https://bugs.launchpad.net/ubuntu/+source/tftp-hpa/+bug/972845 I can did out more references from my browser cache when I`m back at work next week > > >> >> 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. I remove NM in a heartbeat if this wouldnt mean messing up the dependencies and losing gui for applying settings. >> 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 still dont know the difference in meaning between TFTP_ADDRESS=":69" and TFTP_ADDRESS="0.0.0.0:69". And too me the best default would be to just use the default tftp port - thats archived in a most consistent manner by omitting the --address argument (IMHO). Whatever it does, it makes NM and tftp-hpa coexist peacefully, I dont know how long it will take till NM has no bugs. > >> 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. This sounds like the network doesnt "exist" before NM, which I believe to be wrong. It should be possibly to use any ip and unix sockets before services are started? > > >> >> 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. Thats not clear to me, from what I get is that listen on a unbound socket will randomly pick an port, binding to INADDR_ANY:port before should do the same on a fixed one. Might be different with ip6, please enlighten me http://man7.org/linux/man-pages/man7/ip.7.html > >> 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 arguments I red from this is that the TFTP_ADDRESS="0.0.0.0:69" is something desired and it shouldnt surprise anyone if it doesnt work. (I never got the debconf prompt btw) unless you have a laptop and connect to wireless networks, I dont see NM very appealing anyway. But using alternatives is a hassle. > > 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. I agree, but its also a matter of time, isnt it? Until this is fixed correctly I still need to setup some systems for use. Better defaults that happen to work even with the bugs unfixed would be great, a simple configuration or workaround is ok too. >From my experience with wheezy and open-vm-tools, fixed versions in the main repos can take till the next release. > ... which probably isn't really a very high priority for Server Use. > That's much more of a laptop problem. Its a server/workstation problem if the same software packages are used. > > 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 dont WANT to use latptop tools, NetworkManager is the default in pretty much anything with a GUI. I dont want to use it, but using alternatives comes at the cost of maintaining configurations and (dist-)upgrades not working smoothly. Actually I dont even know which gui-packages Id have to replace so I could set my ip and dns in the interfaces file. I meant with out-of-the-box just using the standard GNOME desktop, which should the best maintained and usable for most people that dont know what NM and tftp-hpa is. ie something that safes me work running around and editing files. > > 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 ... I was taking care of the case of all variables or even the defaults file missing (which is handled in the script). You could simply set tftp as username if the variable is missing. > > Cheers, > Ron > > Kind Regards, Norbert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
