bzr.launchpad.net domain name exists but doesn't work

[Ian Jackson]

bzr.launchpad.net exists and responds to ping, but ssh connections time out., while bazaar.launchpad.net works. Users will expect to refer to "bzr" since this is (a) the name of the command and (b) not ambiguous. See transcript:

ian@liberator:~$ sftp -v <email address hidden>
Connecting to bazaar.launchpad.net...
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /home/ian/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to bazaar.launchpad.net [82.211.81.254] port 22.
debug1: Connection established.
debug1: identity file /home/ian/.ssh/id_rsa type 1
debug1: identity file /home/ian/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version Twisted
debug1: no match: Twisted
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
debug1: Miscellaneous failure
No credentials cache found

debug1: Miscellaneous failure
No credentials cache found

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'bazaar.launchpad.net' is known and matches the RSA host key.
debug1: Found key in /home/ian/.ssh/known_hosts:49
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/ian/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = C
debug1: Sending subsystem: sftp
sftp> ^D
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 1.6 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status -1
ian@liberator:~$ sftp -v <email address hidden>
Connecting to bzr.launchpad.net...
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /home/ian/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to bzr.launchpad.net [82.211.81.244] port 22.
[hangs]

[James Henstridge (jamesh)]

I don't think we've ever told people to use the hostname "bzr.launchpad.net" for branch hosting (in fact, the only reference I find to it on google is this bug report).

The hostname resolves because the admins set up a wildcard DNS record to handle the various Launchpad web sites (which I'm not sure was a great idea: while it reduces administration, it can lead to problems like this).

[Ian Jackson (ijackson)]

James Henstridge writes ("[Bug 113792] Re: bzr.launchpad.net does not work with sftp"):
> I don't think we've ever told people to use the hostname
> "bzr.launchpad.net" for branch hosting (in fact, the only reference I
> find to it on google is this bug report).

I typed the domain name from memory. As I said in my report, `bzr' is
should be made to work because it is (a) the name of the command and
(b) not ambiguous (`bazaar' can also refer to baz).

> The hostname resolves because the admins set up a wildcard DNS record to
> handle the various Launchpad web sites (which I'm not sure was a great
> idea: while it reduces administration, it can lead to problems like
> this).

!

Ian.

[Andrew Bennetts (spiv)]

My personal opinion is that I don't think we should have this alias. "There should be one—and preferably only one—obvious way to do it." as the saying goes. One reason why is that eventually people will tend to be using "lp:" URLs instead, once they become better supported. Another reason is that if they both work users are likely to confuse themselves if they sometimes use one and sometimes the other: configuration like .ssh/config and .bazaar/locations.conf will apply inconsistently to what are actually the same locations.

Obviously if we decide that bzr.launchpad.net should not work, then the DNS should be fixed so that bzr.launchpad.net does not resolve, to avoid confusion.

[Martin Pool (mbp)]

I agree with Andrew, and I think that was the consensus of the lpbzr meeting too: the name should just not exist.

It looks like there is a wildcard for this domain:

bzroaeuoeu.launchpad.net. 600 IN A 82.211.81.244

and I think I have seen other bugs about similar confusion. I wonder why?

[James Henstridge (jamesh)]

As far as I can tell, the wildcard domain exists for the convenience of the sysadmins, so they don't need to update the DNS when we add new Launchpad services served by the main webapp. Given the problems it causes, this is probably not a good compromise.

[Matthew Paul Thomas (mpt)]

Bug 74816 is currently "Return HTTP 404 error, not 500, for non-existent domains" (referring to subdomains-of.launchpad.net). If that HTTP(S)-only change wouldn't solve this problem, perhaps it should instead be "Return NXDOMAIN, not 500, for non-existent domains", in which case this bug should be a duplicate.

[Martin Pool (mbp)]

On 7/10/07, Matthew Paul Thomas <email address hidden> wrote:
> Bug 74816 is currently "Return HTTP 404 error, not 500, for non-existent
> domains" (referring to subdomains-of.launchpad.net). If that
> HTTP(S)-only change wouldn't solve this problem, perhaps it should
> instead be "Return NXDOMAIN, not 500, for non-existent domains", in
> which case this bug should be a duplicate.

Right, though obviously the 'returning' would be done at a different
level. Fixing this would also fix bug 74816.

--
Martin

[Stuart Bishop (stub)]

James Henstridge wrote:
> As far as I can tell, the wildcard domain exists for the convenience of
> the sysadmins, so they don't need to update the DNS when we add new
> Launchpad services served by the main webapp. Given the problems it
> causes, this is probably not a good compromise.

There is also the qa side of things. Without the wildcard, new domains need
to be added to the production environment before the code is rolled out,
with enough time for the changes to propagate. If a developer forgets to
notify the admins, or the admins neglect to make the change, entire chunks
of Launchpad are broken.

(I'm not claiming this rationale outweighs the other issues the wildcard
causes, such as ssh/sftp behaviour to non-existant hosts).

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

[James Henstridge (jamesh)]

If I am reading things right, the TTL for a lookup failure on launchpad.net is an hour, and the existing domains are being served with a TTL of 10 minutes. So we aren't talking about huge delays here. As long as the domain gets added an hour before the code gets rolled out we should be fine.

And with the new release process, we should know about any required DNS updates at least a week before release. That should be plenty of time for the admins to sort things out (especially if they know what the deadline is).