http://qa.mandrakesoft.com/show_bug.cgi?id=2829
------- Additional Comments From [EMAIL PROTECTED] 2003-03-12 12:05 ------- Finally got your patch installed. A few minor things as well as some on the addition files in the SRPM would need to be changed in order for it to work after an RPM install. Unfortunately, changing to .localdomain is probably not a good idea. Further research on this, http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-dnsext- mdns-00.txt, shows that .local is the proposed extension for Multicast (notice how M$ is on the list here - most likely explains the Active Directory setups). It would probably be best NOT to install tmdns during installation as a default. For business users, most would already have nameservers so this could be a potential problem. For home users, this service may be useful in a small home network, but it would be easier for them to just install the additional service rather than for a business trying to maintain a large number of machines having to deal with this issue on a much larger scale. Just my 2 cents ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------- Reminder: ------- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: I'm very late on this report, but I've been trying to get it fixed to no avail. I have two boxes, one running 9.0, the other 9.1RC2. Both get an IP address allocated via DHCP and both are on the same network. However, for the 9.1 box it cannot seem to resolve hostnames correctly, forcing you to specify IP addresses in your applications. (Resolving doesn't seem to be working correctly) In both the machines, /etc/resolv.conf looks as follows. (Automagically configured from DHCP) /etc/resolv.conf: nameserver 10.1.1.16 nameserver 10.1.1.10 search af.didata.local Now on the 9.0 box I do a ping (ping terminal.af.didata.local) to a Windows terminal server and it works correctly: [EMAIL PROTECTED] jaco]$ ping terminal.af.didata.local PING terminal.af.didata.local (10.1.0.240) from 10.1.35.66 : 56(84) bytes of data. 64 bytes from terminal.af.didata.local (10.1.0.240): icmp_seq=1 ttl=125 time=0.360 ms ... [EMAIL PROTECTED] jaco]$ >From the 9.1 box I get the following: [EMAIL PROTECTED] jaco]$ ping terminal.af.didata.local ping: unknown host terminal.af.didata.local [EMAIL PROTECTED] jaco]$ Ok, but networking is up and running: [EMAIL PROTECTED] jaco]$ ping 10.1.0.240 PING terminal.af.didata.local (10.1.0.240) from 10.1.35.66 : 56(84) bytes of data. 64 bytes from 10.1.0.240: icmp_seq=1 ttl=125 time=0.374 ms ... [EMAIL PROTECTED] jaco]$ In other news, doing a "ping terminal" on the 9.0 box works, on the 9.1 box not. However, doing a nslookup on "terminal" on both boxes results in the following: [EMAIL PROTECTED] jaco]$ nslookup terminal ... Name: terminal.af.didata.local Address: 10.1.0.240 [EMAIL PROTECTED] jaco]$ Which means that at least that part works. I'm stumped. Any ssh, telnet, rdesktop, etc. to any hostname (with or without the af.didata.local domain) doesn't work. Doing an nslookup and using that IP to connect to, does. The 9.1 machine was upgraded from a working 9.0 box to 9.1RC1 which broke the addresseing. RC2 has not addressed this problem. In addition in 9.1 /etc/hosts still does not contain "127.0.0.1 localhost.localdomain localhost", instead only "127.0.0.1 localhost" which breaks some applications. (eg. Eclipse debugger, not part of main but in full use here) On new bootups the DHCP configuration seems to change it back to "localhost" again, forcing you to make the change manually to get your applications to work.
