URI in API description wrong when accessing machine via alternative interface

[Gavin Panella]

The API description obtained from my location, via the VPN into the test lab, contains URIs like http://192.168.21.1/MAAS/api/1.0/account/. That corresponds to eth0 on that machine, but from my location I'm routing into eth2, with address 10.98.0.13. The API description is thus not usable with maas-cli.

Possible solutions:

* maas-cli should override the netloc,

* The API description should not contain netloc.

* The server should describe itself according to the address by which is was accessed.

[Julian Edwards (julian-edwards)]

Was this fixed?

[Gavin Panella (allenap)]

Nope.

[Launchpad Janitor (janitor)]

This bug was fixed in the package maas - 1.2+bzr1349+dfsg-0ubuntu1

---------------
maas (1.2+bzr1349+dfsg-0ubuntu1) raring; urgency=low

  * New upstream bugfix release. Fixes:
    - The DNS configuration is not created if maas-dns is installed after
      the DNS config has been set up (LP: #1085865).
    - IPMI detection ends up with power_address of 0.0.0.0 (LP: #1064224)
    - Main page slow to load with many nodes (LP: #1066775)
    - maas-cluster-controller doesn't have images for
      provisioning (LP: #1068843)
    - Filestorage is unique to each appserver instance (LP: #1069734)
    - import_pxe_files does not include quantal (LP: #1069850)
    - maas-cli nodes new incomplete documentation (LP: #1070522)
    - DNS forward zone ends up with nonsensical entries (LP: #1070765)
    - The hostname of a node can still be changed once the node is in
      use. (LP: #1070774)
    - The zone name (attached to a cluster controller) can still be changed
      when it contains in-use nodes and DNS is managed. (LP: #1070775)
    - Duplicated prefix in the url used by the CLI (LP: #1075597)
    - Not importing Quantal boot images (LP: #1077180)
    - Nodes are deployed with wrong domain name. (LP: #1078744)
    - src/maasserver/api.py calls request.data.getlist with a 'default'
      parameter. That parameter is not supported by Django 1.3. (LP: #1080673)
    - API calls that return a node leak private data (LP: #1034318)
    - MAAS hostnames should be 5 easily disambiguated characters (LP: #1058998)
    - URI in API description wrong when accessing machine via alternative
      interface. (LP: #1059645)
    - Oops when renaming nodegroup w/o interface (LP: #1077075)
    - Error in log when using 'Start node' button: MAASAPINotFound: No user
      data available for this node. (LP: #1069603)

  [ Raphaël Badin ]
  * debian/maas-dns.postinst: Call write_dns_config (LP: #1085865).
  * debian/maas-dns.postinst: fix permissions and group ownership of
    file /etc/bind/maas/named.conf.rndc.maas. (LP: #1066935)

  [ Julian Edwards ]
  * debian/maas-region-controller.install: Remove installation of maas-gc; it
    is no longer required as upstream no longer stores files in the filesystem.
    (LP: #1069734)
  * debian/maas-cluster-controller.postinst: Ensure that /etc/maas/pserv.yaml
    is updated when reconfiguring. (LP: #1081212)

  [ Andres Rodriguez ]
  * debian/control:
    - maas-cluster-controller Conflicts with tftpd-hpa (LP: #1076028)
    - maas-dns: Conflicts with dnsmasq
    - Drop Dependency on rabbitmq-server for maas-cluster-controller.
      (LP: #1072744)
    - Add conflicts/replaces for maas-region-controller to
      maas-cluster-controller.
  * debian/maas-cluster-controller.config: If URL has been detected, add
    /MAAS if it doesn't contain it. This helps upgrades from versions where
    DEFAULT_MAAS_URL didn't use /MAAS.
  * Install maas-import-pxe-files and related files with
    maas-cluster-controller, as well as configure tgtd, as
    maas-region-controller no longer stores images. Thanks to Jeroen
    Vermuelen.

  [ Gavin Panella ]
  * debian/extras/99-maas: squashfs image download is no longer needed.
  * debian/maas-clu...

[Launchpad Janitor (janitor)]

This bug was fixed in the package maas - 1.2+bzr1373+dfsg-0ubuntu1

---------------
maas (1.2+bzr1373+dfsg-0ubuntu1) quantal-proposed; urgency=low

  * MAAS Stable Release Update (LP: #1109283):
    This SRU brings a new upstream release of MAAS that removes
    the usage of a cobbler code copy, 'maas-provision' as well as
    several bug fixes. Exception has been granted by the Technical
    Board to proceed. More information can be found in:
    https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-February/001012.html

  [ Andres Rodriguez ]
  * debian/control:
    - Change Conflicts/Replaces for Breaks/Replaces.
    - Conflicts on tftpd-hpa and dnsmasq.
    - Do not pre-depends, but Depends on ${misc:Depends} for 'maas'.

  [ Steve Langasek ]
  * postinst scripts are never called with 'reconfigure' as the script
    argument. Remove references to this (mythical) invocation.
  * always call 'set -e' from maintainer scripts instead of passing 'sh -e'
    as the interpreter, so that scripts will behave correctly when run via
    'sh -x'.
  * invoke-rc.d is never allowed to not exist - simplify scripts (and make
    them better policy-compliant) by invoking unconditionally. (The only
    possible exception is in the postrm, where it's *theoretically* possible
    for invoke-rc.d to be missing if the user has completely stripped
    down their system; that's a fairly unreasonable corner case, but we
    might as well be correct if it ever happens.)
  * db_get+db_set is a no-op; don't call db_set to push back a value we just
    got from db_get.
  * Omit superfluous calls to 'exit 0' at the end of each script.
  * Remove maas-cluster-controller prerm script, which called debconf for no
    reason.
  * Don't invoke debconf in the postrm script either, debhelper already does
    this for us.
  * Other miscellaneous maintainer script fixes
  * debian/maas-common.postinst: call adduser and addgroup unconditionally;
    the tools are already designed to DTRT, we don't need to check for the
    user/group existence before calling them nor should we worry about
    calling them only once on first install.
  * debian/maas-common.postrm: delete the maas group, not just the user,
    as the comment in the code implies we should do.
 -- Andres Rodriguez <email address hidden> Thu, 07 Mar 2013 14:22:35 -0500