Ticket #245 (closed defect: workaround)
127.0.1.1 breaks 3partysw license managers
Reported by: | alexp | Owned by: | |
---|---|---|---|
Priority: | trivial | Milestone: | The Distant Future |
Component: | -- | Keywords: | |
Cc: | alexp | Fixed in version: | |
Upstream bug: |
Description (last modified by jdreed) (diff)
On Apr 3, 2009, at 6:07 PM, Anders Kaseorg wrote:
127.0.1.1 zippy zippy.mit.edu
is denied, but
127.0.1.1 zippy.mit.edu
is allowed.
This probably happens because hostname -i will be 127.0.1.1 in the
former case, but 18.142.4.128 in the latter case. So this is another
manefestation of the known problem with 127.0.1.1.
Thanks for the information; we really need to solve the problem though; do
we do that by making sure all hosts on those lines are fully qualified?
To be clear, the problem is not that there is a non-fully-qualified
hostname in /etc/hosts. The problem is that because your kernel’s
hostname is zippy, which is resolved by /etc/hosts to 127.0.1.1, license
managers that have a client-side ACL of IP addresses (like 18.*) get
confused.
If, as you did, you take zippy out of /etc/hosts (leaving only
zippy.mit.edu), then zippy is resolved by DNS to 18.142.4.128 using the
search path and servers in /etc/resolv.conf, and the license manager
presumably becomes less confused.
A better client-side workaround is to put the right IP address in
/etc/hosts:
18.142.4.128 zippy zippy.mit.edu
which is what I think the Ubuntu installer does if you configure it with a
static IP address at install time. (For the cluster machines, we
currently don’t.)
We are currently discussing possible solutions on zephyr.
Change History
comment:2 Changed 15 years ago by andersk
Solutions I think are good:
- Check whether we can avoid the problem entirely by putting 127.0.1.1 in the license manager ACL.
- Work with upstream vendors to fix their shit licensing managers.
- Set up cluster machines with a static IP at install time instead of installing with DHCP and then hacking it later.
- If all else fails, detect the problem from the affected third party wrapper scripts by testing [ "$(hostname -i)" = 127.0.1.1 ] and tell the user how to work around this license manager bug, being clear about whose fault the problem is and what the potential consequences of the workaround are.
Solutions I think should be rejected immediately:
- Anything that involves automatically modifying /etc/hosts from a Debathena package.
We have more than enough solutions in the “good” category to stay far away from that territory. Breaking a DHCP user’s networking config in subtle ways is just plain mean.
comment:3 follow-up: ↓ 4 Changed 15 years ago by alexp
- Cc alexp added
- Check whether we can avoid the problem entirely by putting 127.0.1.1 in
the license manager ACL.
Well, this would most likely let anyone on the internet use our licenses and totally defeat the purpose of limiting access by IP address as far as I can tell.
- Work with upstream vendors to fix their shit licensing managers.
I've already done this in both cases where it has come up so far. At least in one (the RLM license server people) they've indicated at least a willingness to address the issue, though not in the near term.
- Set up cluster machines with a static IP at install time instead of
installing with DHCP and then hacking it later.
I think this is the only viable option left.
- If all else fails, detect the problem from the affected third party
wrapper scripts by testing [ "$(hostname -i)" = 127.0.1.1 ] and tell the
user how to work around this license manager bug, being clear about whose
fault the problem is and what the potential consequences of the workaround
are.
What are the potential consequences?
Alex
comment:4 in reply to: ↑ 3 Changed 15 years ago by andersk
Replying to alexp:
- Check whether we can avoid the problem entirely by putting 127.0.1.1 in
the license manager ACL.
Well, this would most likely let anyone on the internet use our licenses and totally defeat the purpose of limiting access by IP address as far as I can tell.
Does it work, though? If it does work, that means that
- Anyone on the internet can _already_ use our licenses, by modifying their /etc/hosts to pretend to have a MITnet address.
- We can solve that problem for real by limiting access to the licensing servers _on the server side_, either by appropriate server configuration or by just firewalling away non-MITnet addresses.
- If all else fails, detect the problem from the affected third party
wrapper scripts by testing [ "$(hostname -i)" = 127.0.1.1 ] and tell the
user how to work around this license manager bug, being clear about whose
fault the problem is and what the potential consequences of the workaround
are.
What are the potential consequences?
The kind of thing that generally tends to happen is that certain applications will randomly break if you stop having the IP address you said you have (e.g. your network goes away, or your DHCP address changes). Problems I’ve seen include sudo starting to fail, or GNOME login being really slow because internal network connections to hostname are timing out, even if most of the system appears to be working. These kinds of problems are nonobvious and _really_ hard to track down to an /etc/hosts mistake, especially if the user has no clear indication that the problem is their fault.
This is why Debian and Ubuntu intentionally use 127.0.1.1 in /etc/hosts for machines with dynamic addresses http://www.debian.org/doc/manuals/reference/ch-gateway.en.html#s-net-dns.
comment:5 Changed 15 years ago by geofft
- Priority changed from major to low
- Milestone changed from Fall Release to IAP 2010
At release-team on Tuesday, alexp said the two applications that still had trouble were Tecplot, which he could control the ACL for, and the Cambridge Structural Database, which he couldn't. He added 127.0.1.1 to the ACL for Tecplot, and andersk confirmed that he couldn't run the software from off-campus (i.e., both the client and the server check the IP address list). So Tecplot should be fixed.
alexp says that there are very few CSD users, so at this point, documentation on how to edit /etc/hosts manually (note that you can do this on -cluster systems within your sandbox...) ought to be sufficient, so I'm going to downgrade the priority and due date.
As far as real solutions, it's probably the case that upstream network-manager should go around frobbing /etc/hosts (or hooking NSS or something cleaner) if the current network configuration involves a static address.
comment:6 Changed 15 years ago by broder
What was the resolution on this? I thought there were action items at some point for people to test those applications, but I don't remember the results. Can we close this?
comment:7 Changed 15 years ago by alexp
I think it's been resolved as best as it can be for now. There's only one Third Party app, the Cambridge Structural Database, that we don't have a workaround for (other than editing /etc/hosts). It's low-volume and the vendor is aware of the issue.
Alex
comment:8 Changed 14 years ago by jdreed
- Milestone changed from Summer 2010 (Lucid Deploy) to The Distant Future
comment:10 Changed 11 years ago by jdreed
Can we close this?
comment:11 Changed 10 years ago by jdreed
- Status changed from new to closed
- Resolution set to workaround
Closing. I think the fact that we've been using Real(tm) static IPs on cluster in stage2 for a while now, and that Network Manager does clever things with dnsmasq now, means that this is no longer an issue. If it's an issue for the occasional debathena-not-cluster user using Cambridge Structural Database, we can document a workaround.