Activity log for bug #871966

Date Who What changed Old value New value Message
2011-10-10 19:35:34 Clint Byrum bug added bug
2011-10-10 19:45:38 Launchpad Janitor cloud-init (Ubuntu): status New Confirmed
2011-10-10 19:57:11 Clint Byrum bug task added cassandra (juju Charms Collection)
2011-10-10 20:20:01 James Page bug added subscriber James Page
2011-10-11 19:32:10 Clint Byrum cassandra (juju Charms Collection): status New In Progress
2011-10-11 19:32:16 Clint Byrum cassandra (juju Charms Collection): assignee James Page (james-page)
2011-10-11 19:32:22 Clint Byrum cloud-init (Ubuntu): importance Undecided Low
2011-10-11 19:33:39 Clint Byrum bug task added ubuntu-release-notes
2011-10-11 19:35:27 Clint Byrum description By writing the FQDN to /etc/hosts as resolving to 127.0.1.1, systems like Cassandra have a much harder time determining their address to communicate to other cluster members. While some might see communicating your IP to others as a bug, being able to use gethostname() and then resolving it to get the actual IP address of one's machine is fairly important. Its my understanding that in resolving bug #802637 , the Debian networking docs were used as a guide: http://www.debian.org/doc/manuals/debian-reference/ch05.en.html Point 5.1.2 specifically. It does suggest that one needs an FQDN in /etc/hosts. However cloud-init should only set the addresss if it cannot be determined. cloud-init should first try gethostbyname() on the FQDN. If it resolves, *do not write FQDN to /etc/hosts*. This assures that if it has been configured to be resolvable by some method in nsswitch.conf such as DNS or NIS or etc., it will not be overidden by /etc/hosts. *** Ubuntu 11.10 Release Note *** Cloud instances and servers pre-seeded with cloud-init will have their FQDN written to /etc/hosts and pointed to the IP 127.0.1.1. This may cause issues for daemons which try to listen on their hostname, rather than 0.0.0.0, as they will now only be reachable locally, rather than on the network address that their FQDN resolves to. *** By writing the FQDN to /etc/hosts as resolving to 127.0.1.1, systems like Cassandra have a much harder time determining their address to communicate to other cluster members. While some might see communicating your IP to others as a bug, being able to use gethostname() and then resolving it to get the actual IP address of one's machine is fairly important. Its my understanding that in resolving bug #802637 , the Debian networking docs were used as a guide: http://www.debian.org/doc/manuals/debian-reference/ch05.en.html Point 5.1.2 specifically. It does suggest that one needs an FQDN in /etc/hosts. However cloud-init should only set the addresss if it cannot be determined. cloud-init should first try gethostbyname() on the FQDN. If it resolves, *do not write FQDN to /etc/hosts*. This assures that if it has been configured to be resolvable by some method in nsswitch.conf such as DNS or NIS or etc., it will not be overidden by /etc/hosts.
2011-10-13 06:07:02 Kate Stewart ubuntu-release-notes: status New Incomplete
2011-10-13 06:07:10 Kate Stewart ubuntu-release-notes: status Incomplete Fix Committed
2011-10-13 08:41:57 James Page cassandra (juju Charms Collection): status In Progress Fix Released
2011-10-19 17:08:46 Kate Stewart nominated for series Ubuntu Precise
2011-10-19 17:08:46 Kate Stewart bug task added cloud-init (Ubuntu Precise)
2011-10-19 17:08:56 Kate Stewart ubuntu-release-notes: status Fix Committed Fix Released
2011-11-15 20:39:43 Scott Moser description *** Ubuntu 11.10 Release Note *** Cloud instances and servers pre-seeded with cloud-init will have their FQDN written to /etc/hosts and pointed to the IP 127.0.1.1. This may cause issues for daemons which try to listen on their hostname, rather than 0.0.0.0, as they will now only be reachable locally, rather than on the network address that their FQDN resolves to. *** By writing the FQDN to /etc/hosts as resolving to 127.0.1.1, systems like Cassandra have a much harder time determining their address to communicate to other cluster members. While some might see communicating your IP to others as a bug, being able to use gethostname() and then resolving it to get the actual IP address of one's machine is fairly important. Its my understanding that in resolving bug #802637 , the Debian networking docs were used as a guide: http://www.debian.org/doc/manuals/debian-reference/ch05.en.html Point 5.1.2 specifically. It does suggest that one needs an FQDN in /etc/hosts. However cloud-init should only set the addresss if it cannot be determined. cloud-init should first try gethostbyname() on the FQDN. If it resolves, *do not write FQDN to /etc/hosts*. This assures that if it has been configured to be resolvable by some method in nsswitch.conf such as DNS or NIS or etc., it will not be overidden by /etc/hosts. *** Ubuntu 11.10 Release Note *** Cloud instances and servers pre-seeded with cloud-init will have their FQDN written to /etc/hosts and pointed to the IP 127.0.1.1. This may cause issues for daemons which try to listen on their hostname, rather than 0.0.0.0, as they will now only be reachable locally, rather than on the network address that their FQDN resolves to. *** By writing the FQDN to /etc/hosts as resolving to 127.0.1.1, systems like Cassandra have a much harder time determining their address to communicate to other cluster members. While some might see communicating your IP to others as a bug, being able to use gethostname() and then resolving it to get the actual IP address of one's machine is fairly important. Its my understanding that in resolving bug #802637 , the Debian networking docs were used as a guide: http://www.debian.org/doc/manuals/debian-reference/ch05.en.html Point 5.1.2 specifically. It does suggest that one needs an FQDN in /etc/hosts. However cloud-init should only set the addresss if it cannot be determined. cloud-init should first try gethostbyname() on the FQDN. If it resolves, *do not write FQDN to /etc/hosts*. This assures that if it has been configured to be resolvable by some method in nsswitch.conf such as DNS or NIS or etc., it will not be overidden by /etc/hosts. related bugs: bug 890501: EC2 cloud-init overwrites 127.0.1.1 in /etc/hosts on every reboot
2011-11-15 20:40:36 Scott Moser bug task added cloud-init
2011-12-20 01:34:54 Scott Moser cloud-init: status New Triaged
2011-12-20 01:34:57 Scott Moser cloud-init: importance Undecided Medium
2011-12-20 01:35:00 Scott Moser cassandra (juju Charms Collection): importance Undecided Medium
2011-12-20 03:49:25 Launchpad Janitor branch linked lp:cloud-init
2011-12-20 03:50:35 Scott Moser cloud-init (Ubuntu Precise): status Confirmed Fix Committed
2011-12-20 03:52:35 Scott Moser cloud-init (Ubuntu Precise): status Fix Committed Triaged
2011-12-20 03:52:40 Scott Moser cloud-init: status Triaged Fix Committed
2011-12-20 03:52:45 Scott Moser cloud-init: assignee Scott Moser (smoser)
2011-12-20 03:52:49 Scott Moser cloud-init (Ubuntu Precise): assignee Scott Moser (smoser)
2011-12-22 09:10:13 Launchpad Janitor cloud-init (Ubuntu Precise): status Triaged Fix Released
2011-12-22 09:10:30 Launchpad Janitor branch linked lp:ubuntu/cloud-init
2012-01-18 22:17:10 Tom vN bug added subscriber Tom vN
2012-04-11 04:07:44 Scott Moser cloud-init: status Fix Committed Fix Released
2023-05-09 18:33:54 James Falcon bug watch added https://github.com/canonical/cloud-init/issues/2215