hostname -f does not return a proper FQDN

I bet money that hostname -f tells you localhost.localdomain.

I fixed it by modifying /etc/hosts.

/Erik

(In reply to comment #0)
> If you start a remote desktop session off, it only gives you the connection
> string for localhost.
> i.e: localhost.localdomain:0
>
> This should be either the actuall machine name (i.e. fqdn) or the IP address.
> If this is sent to a 3rd person, they would only be trying to connect to
themselfs,
> rather than the actual target machine.
>
> My machine is fully up to date and is running a FQDN as resolved from internal
DNS.

I get the same, If I modify /etc/hosts, it seems to report the correct name
I could be stupid, but IMHO vino should know that localhost.localdomain is a
waste of time.

Also it should detect any network cards and use the name from that if possible,
should this (IMHO) a major bug (that does not fit in with GNOME's it Just works),
as users should not expect to have to edit this to get it to work.

The sort of people who would generally be using this (apart from sys admins, who
would probably use ssh instead)
are probably using it to request assistance for some tech support,
so this should be made as easy as possible for them.

Should this get filed upstream in GNOME's bugzilla?

Not a gnome bug.

The default /etc/nsswitch.conf is configured to look in /etc/hosts first, then
in dns. changing the host lookup to

    hosts: dns [!UNAVAIL=return] files

gets you the fqdn. This works without timeout, even if the name server is
unreachable or your network cable isn't plugged in (but in this case you still
get localhost.localdomain.

Maybe

    hosts: dns [!UNAVAIL=tryagain] files

is a safer default setting.

Not sure whether the bug is the default nsswitch.conf, or whatever is writing
/etc/hosts, but neither can be changed for Warty. The effects are too far-reaching.

Will this be closed, or are you leaving this bug report open
for future releases?

Nothing has been changed yet, so I don't see that the bug report can be closed.

Matt: I think netcfg is the right place for any fix, so reassigning.

The bug will stay open until it is fixed

Comparing with Debian install, it would seem that the major difference is the
ordering of domain names in the first line of /etc/hosts
e.g, standard Debian:
127.0.0.1 nanook localhost

vs Ubuntu:
127.0.0.1 localhost.localdomain localhost nanook

> e.g, standard Debian:
> 127.0.0.1 nanook localhost
>
> vs Ubuntu:
> 127.0.0.1 localhost.localdomain localhost nanook

The latter is also how Debian sarge sets up /etc/hosts.

This won't be changed for sarge.

I believe that a better solution is

127.0.0.1 localhost.localdomain localhost
127.0.1.1 nanook.nanooksdomain nanook

so that localhost.localdomain is the canonical hostname for
localhost.localdomain and localhost
and nanook.nanooksdomain is the canonical hostname for nanook.nanooksdomain and
nanook.
Obviously, if the machine has a permanent network adapter with a static IP
address then
the latter IP address should be used instead of 127.0.1.1.

In any case, I hope that Debian and Ubuntu adopt the same policy on this issue.

If you get your hostname and domain name from the net, i.e. a DHCP server, then
any entry in /etc/hosts is outdated and should be overwritten. For this case I
still think that the order 'dns files' in /etc/nsswitch.conf is the right thing.
Proposing the change, there's time to test and eventually revert this change.

This problem is still present in Dapper. Among other things it affects the ability of Postfix to operate as configured in Ubuntu:

From Postconf 5:

http://www.postfix.org/postconf.5.html#myhostname

"The default is to use the fully-qualified domain name from gethostname."

So, Postfix is expecting the standard C function gethostname to produce a
FQDN. I decided to test this. First by removing myhostname from main.cf and
then by accessing the C function as directly as I could. Fortunately, Python
gives almost direct access to this function in its socket module:

http://www.python.org/doc/2.4.3/lib/module-socket.html

So, through Python, I call the same function (this is on an Ubuntu server):

mailout00:~$ python
Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> print socket.gethostname()
mailout00

Just the machine name, not a FQDN.

Here is the same thing on a FreeBSD 4.8-STABLE machine:

raung% python
Python 2.4.1 (#1, Jun 10 2005, 16:38:07)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> print socket.gethostname()
raung.pair.com

Just to make sure, Python also has another function called getfqdn.

Ubuntu:

mailout00:~$ python
Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> print socket.getfqdn()
mailout00

FreeBSD:

raung% python
Python 2.4.1 (#1, Jun 10 2005, 16:38:07)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> print socket.getfqdn()
raung.pair.com

I think I understand this better now... I built a new server today and running the same script I get:

Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> print socket.getfqdn()
mailout02.controlledmail.com

or to get back to the original report:

$ hostname -f
mailout02.controlledmail.com

As you can see, it works just fine. The difference (this is the first time out of 4 machines, all Dapper fresh installs all using the text mode installer) I believe is that this time I had the reverse DNS PTR record set in advance. When setting up networking the installer offered mailout02 as the hostname and then clearly picked up the rest of the FQDN from the IP address' PTR record.

It seems to me now that the error is to only ask for the machine's name and not the domain name if it can't be picked up from a PTR record.

I have a system that started as breezy, and has been updated to dapper then edgy.
My hostname is 'marvin'.

By default, the first entry in /etc/hosts read
127.0.0.1 localhost.localdomain localhost marvin

A later entry reads
192.168.13.2 marvin.chile.gen.nz marvin

If I move the localhost entry to the end of the file, hostname -f returns 'marvin.chile.gen.nz' rather than 'localhost.localdomain'. This suggests that the order of entries in /etc/hosts is critical.

Not necessarily (about the order being important). On both Dapper and Edgy (as fresh installs) I have (for example):

/etc/hosts
127.0.0.1 localhost
70.91.79.100 mailout01.controlledmail.com mailout01

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

$ hostname -f
mailout01.controlledmail.com

From the problematic box mentioned in my previous comment (Dapper upgraded to Edgy) I have:

/etc/hosts

127.0.0.1 localhost
72.81.252.19 mailout00

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

$ hostname -f
mailout00

If I change /etc/hosts to add the fqdn to it, I get:

$ hostname -f
mailout00.controlledmail.com

The basic problem that I think this bug is about is that /etc/hosts is not populated correctly by the installer. I suspect if you take marvin out of the 127.0.0.1 entry, you will get the correct result. The current installer does not appear to add it.

[23:23] <scotth> its a pretty old install that I believe started with dapper and is now at gutsy
[23:24] * ScottK wonders if Bug #8980 might be relevant.
[23:24] <ubotu> Launchpad bug 8980 in netcfg "hostname -f does not return a proper FQDN" [Medium,Confirmed] https://launchpad.net/bugs/8980
[23:26] <scotth> ScottK: that got it, reordering to outkast.sjhserv.net outkast got the fqdn working

I expected hostname to return the value for eth0, which in this instance is currently 192.168.101.100. A related bug is that lo is not up.

$ hostname -i
127.0.1.1
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:1b:63:92:3e:85
          inet addr:192.168.101.100 Bcast:192.168.101.255 Mask:255.255.255.0
          inet6 addr: fe80::21b:63ff:fe92:3e85/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:198577 errors:0 dropped:0 overruns:0 frame:0
          TX packets:125590 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:287827105 (274.4 MB) TX bytes:9484088 (9.0 MB)
          Interrupt:18
$
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"
$ dpkg -l hostname | grep ii
ii hostname 2.94 utility to set/show the host name or domain name
lars@macbook:~$

Wow this is a 4-year old bug! and still "Confirmed"

Ubuntu is dealing with 'enterprise-grade servers' and we have a bug about /etc/hosts ???

> Wow this is a 4-year old bug! and still "Confirmed"
>
> Ubuntu is dealing with 'enterprise-grade servers' and we have a bug about /etc/hosts ???

How is this a helpful comment?

Do you have further information about this bug? Does it still happen in a fresh install of recent release?

I'm guessing it's not too important, because otherwise there would have been more comments here. I had a problem with this issue a couple of years ago (which is how I'm subscribed to the bug and saw your comment) but it hasn't been an issue since.

Still happens on a fresh gutsy install.

I have to admit my comment wasn't helpful at all.

I don't have "sudo" problems yet (and NOT looking forward to it! Especially not on a remote server.)

But there are some things:
* I never had any idea that /etc/hosts has a connection with the wellbeingness of "sudo"
* I've had sudo problems a few times before, but it seems to be related to incorrect time (time too future?). Rebooting "usually" works, IF you can get reboot privileges that is :-(
* There are gazillions of different opinions on how is the "best" /etc/hosts structure. All seem to agree to disagree. Each distro has their own preferred layout, and even in Ubuntu there are several different layouts depending on situation. This needs to be clarified. At least, make it an official document that describes the "rationale" behind the *official* Ubuntu /etc/hosts layout.
* Setting hostname is, I have to say, tricky.

I had to experiment with different /etc/hostname and /etc/hosts to get the effect that I "want".

i.e.:
* hostname returns the "proper" hostname (is this supposed to be short or long?)
* hostname -s returns the proper short hostname
* hostname -f returns the proper FQDN hostname
* all apps that auto-detects hostname is working
* Samba, Avahi, sudo, etc. doesn't have problems
* can detach and attach from the network anytime (with or without roaming), both on wired and wireless
* domain name lookups to itself doesn't conflict (i.e. by setting "mymachine.example.com" as 127.0.0.1, if an app looks up its own host then gives its IP address to other machine, then it would be incorrect)

I've had several times when calling hostname returns "localhost" or similar.

Another issue is that on my fresh Ubuntu Gutsy 7.10 Server x86_64 install, I don't get "localhost.localdomain" on the /etc/hosts. I'm not sure if that's critical, but the point is this is confusing.

I don't know who is right.

Personally I've had no trouble with sudo. I'm not sure what that's about.
This really isn't more than a nuisance for an experienced admin, but it
would be nice to get it fixed.

I think I'm an experienced admin.

I just setup two load balanced Ruby on Rails Mongrel cluster applications with Apache 2 and proxy_balancer with less difficulty than I had trying to make sure I had the server's hostname properly (with the added intimidation that I could lose sudo access!) :-(

What's this concern about losing sudo access? The comment https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/8980/comments/20 is the first time it has been mentioned here.

davee,

Check these out:
http://www.google.com/search?q=hostname+sudo+ubuntu

Which turns up: (among others)
https://bugs.edge.launchpad.net/ubuntu/+source/sudo/+bug/32906
https://bugs.edge.launchpad.net/ubuntu/+source/sudo/+bug/188424
https://bugs.launchpad.net/bugs/9471
https://bugs.edge.launchpad.net/bugs/32906

There seems to be no way to relate bugs without marking them as duplicate, so I'll let this like this.

Note that the sudo/hostname combo bug still applies to Hardy:

"just updated to 8.04 and that either messed up my hostname or it's not good for sudo anymore, I'm a bit confused at the moment"
https://bugs.edge.launchpad.net/ubuntu/+source/sudo/+bug/32906

This also causes problems with winbind/samba, since 'net ads join' cannot join the domain unless the domain portion of the hostname matches the AD domain/realm

JMX services are also affected by the incorrect response provided by 'hostname -i'.
This seems to be more a DHCP problem than anything else.
Once a valid DHCP lease is obtained, the /etc/hosts file should have a proper configuration set.
This is the root of all evil :)

PS.: The issue is still present on Gutsy.

Still present in Hardy Heron.

$ hostname -i
127.0.1.1

$ lsb_release -rcd
Description: Ubuntu 8.04
Release: 8.04
Codename: hardy
$ uname -a
Linux macbook 2.6.24-18-generic #1 SMP Wed May 28 19:28:38 UTC 2008 x86_64 GNU/Linux

Still present in Intrepid too.

That hostname -i returns 127.0.1.1 is not a bug.

In contemporary Debian and Ubuntu, /etc/hosts should look like this:

    127.0.0.1 localhost
    127.0.1.1 foo

where "foo" is the Linux hostname and the content of /etc/hostname.
If the machine has a permanent IP address (123.45.67.89) and FQDN
(foo.bar.com) then it should look like this:

    127.0.0.1 localhost
    123.45.67.89 foo.bar.com foo

In the latter case "hostname -f" returns "foo.bar.com".

This is standard in Debian and Ubuntu and satisfies a number of desiderata:
* The hostname resolves to an address which resolves back the hostname or its FQDN variant
* "localhost" resolves to 127.0.0.1 which resolves back to "localhost"
* Each hostname resolves to a single IP address
* Each IP address resolves to a single canonical hostname
* The Linux hostname is resolvable

If software does not work with this configuration then that software is buggy.

It looks to me as if this report can be closed.

We do still seem to have some problems:

127.0.0.1 sarantium localhost.localdomain localhost
127.0.1.1 sarantium.pelham.vpn.ucam.org sarantium

This machine was originally installed with an alpha CD of gutsy, dated 20070911. This is, to say the least, odd since netcfg at the time made no mention of localhost.localdomain. I have a feeling that there are some problems elsewhere even if they aren't in netcfg, and would like to look into those rather than simply closing this bug.

Ah, I see what the problem is! network-manager overwrites /etc/hosts with a bogus version that:

  * sticks the short hostname into 127.0.0.1, when it was already in 127.0.1.1 previously
  * gratuitously adds localhost.localdomain

The result of this is indeed that 'hostname -f' stops returning the FQDN.

I haven't been able to trigger this behaviour on demand, but looking into network-manager it does still appear to be present. Alexander, could you sync up the update_etc_hosts function in NetworkManager with the behaviour described by Thomas Hood in the comment before this one, implemented by netcfg, so that we can have a single standard policy for /etc/hosts across the distribution?

Scott Kitterman says on IRC that he has seen this on servers without NetworkManager. In that case, I need to see the /etc/hosts file, and I need to know what the machine was installed from (the simplest way to tell me this is to attach /var/log/installer/syslog). Please do not reassign this bug back from network-manager unless your contention is that there is *also* no bug in network-manager; instead, add a bug task on netcfg.

 hostname -f
mailout02

As far as I can tell from Scott's logs, he simply didn't tell netcfg about his domain name at installation time, and so it couldn't write it to /etc/hosts.

I have a vague recollection that in some cases I got asked and in some I
didn't, but it's been a while sine I did this install. I'm sure if I got
asked, I'd have answered.

I think the hostname question is not particularly clear about the fact that you can enter an FQDN (the expectation upstream is that a separate domain question would be asked, but we decided it only needed one question). We should fix this.

I just did test installs of 8.04.2 and 9.04 alpha 3, using the i386 alternate ISO in each case. I answered the question about the hostname by supplying the FQDN in each case. Immediately on completion of each install, I checked the various files.

For the jaunty alpha, the domain was correctly split, the unqualified hostname was placed in /etc/hostname, and the entry for 127.0.1.1 in /etc/hosts had the FQDN then the unqualified host name. However, there is no domain entry in /etc/resolv.conf

For the 8.04.2 install, the FQDN went into /etc/hostname, and /etc/hosts had
127.0.0.1 localhost
127.0.1.1 host.dom.ain.dom.ain host.dom.ain

- ie the domain was duplicated.

I then checked the General tab of network-admin on the newly-installed 8.04.2, and found the FQDN in the host field, while the domain field was blank. An attempt to change the details using network-admin updated /etc/hostname and /etc/resolv.conf, but did not update /etc/hosts (although the timestamp for all 3 files was updated). The update to /etc/resolv.conf was to append a domain line. (The domain line will disappear next time Network Manager over-writes /etc/resolv.conf with DNS server details learnt from DHCP, but that is a separate bug.)
Because there is no line in /etc/hosts with an entry matching the value in /etc/hostname, hostname succeeds, but 'hostname -f' fails with 'hostname: Unknown host'.

I think the two issues here should be disentangled. In particular I think the problem with NetworkManager should be split out and tracked as a separate bug.

To be clear the problem with NetworkManager is that it doesn't take the complete set of actions necessary so that "hostname -f" and gethostbyname(2) return the correct domainname. In NetworkManager cases the /etc/network/interfaces is just:

auto lo
iface lo inet loopback

Everything else is handled by NetworkManager. NetworkManager correctly constructs /etc/resolv.conf. It needs to do something else: either rewrite /etc/hosts or something.

Users should NOT be required to edit /etc/hosts unless they have special requirements when using NetworkManager. All the info comes from DHCP.

Does this issue occur in Lucid?

Yes. And in Maverick.

In Maverick, NetworkManager already does rewrite /etc/hosts with some amounts of success.

FWIW, I can also pretty nicely workaround having the FQDN available or not by adding just the domain part in /etc/domainname. It's not pretty but it does work, and from there on connection I have /etc/hosts looking like this:

10.13.18.19 demeter.cyphermox.net demeter # Added by NetworkManager
127.0.0.1 localhost.localdomain localhost
::1 demeter.cyphermox.net demeter localhost6.localdomain6 localhost6
127.0.1.1 demeter

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Without something in /etc/domainname only the shortname is available, but that still does the right thing for the majority of users (I think)... no?

In Maverick, the rewrite of /etc/hosts causes the "idmapd" daemon to think that the current domain is "localdomain".

... no, that's not the only thing; does Network Manager set the hostname to localhost.localdomain? Because fixing /etc/hosts with "chattr +i" when running networkmanager will still cause idmapd to think that it's current domain is "localdomain".

Hello,

it also prevents duplicity (Backup Software) from running:

Last full backup date: Tue Nov 2 10:12:12 2010
Fatal Error: Backup source host has changed.
Current hostname: localhost6.localdomain6
Previous hostname: lain.office.noris.de

Aborting because you may have accidentally tried to backup two different data sets to the same remote location, or using the same archive directory. If this is not a mistake, use the --allow-source-mismatch switch to avoid seeing this message
Duplicity failed.

For me the problem occurs because it adds "lain" to ::1 as an alias (which is wrong). The line looks like this:

::1 lain localhost6.localdomain6 localhost6

FYI It looks like this issue is also being discussed in the following bug reports.

Hostname change blocks backup after upgrade to maverick
https://bugs.launchpad.net/duplicity/+bug/662334

NetworkManage does not set domain in /etc/hosts on DHCP connections
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/659817

Here is my view of the problem: On an up-to-date Maverick install, if /etc/hosts looks like the following on bootup...

--------
127.0.0.1 localhost
127.0.1.1 hostname.intra.example.com hostname

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
--------

...NetworkManager changes it (syslog: "<info> Updating /etc/hosts with new system hostname") to this:

--------
127.0.0.1 hostname localhost.localdomain localhost
::1 hostname localhost6.localdomain6 localhost6
127.0.1.1 hostname.intra.example.com hostname

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
--------

With that, "hostname -f" incorrectly returns just the unqualified hostname.

I think part of the problem is the layout convention being used for /etc/hosts. The first example above was the result of the Ubuntu alternate installer. On a different system installed with Ubiquity, however, I have this (note that this system does not have a domain part, so I can't tell if "hostname -f" is broken or not):

--------
192.168.1.XX hostname # Added by NetworkManager
127.0.0.1 localhost.localdomain localhost
::1 hostname localhost6.localdomain6 localhost6
127.0.1.1 hostname

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
--------

I think N-M's logic for modifying /etc/hosts may not be robust enough to generate a correct file given some of these inputs.

At last I got hostname -i and hostname -f to work (hostname -I did work all the time).
In my case, the setup of dhclient and the DSL modem did not play well together:
https://bugs.launchpad.net/ubuntu/+source/dhcp/+bug/694290
furthermore, I have adjusted /etc/hosts along the lines in this bug.

This was a painful process, especially as it was required to get dpkg to proceed.
I am disappointed at the several days it is taking to install lucid on a new computer.

network-manager appears to be working sanely now, in Natty.

Could anyone affected by this bug in recent memory please check to see if the problem persists in the latest released Ubuntu?

(It would be nice to finally close this report, after almost seven years...)

$ hostname -f
kubuntu

$ lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04

Although problems with resolving the local hostname appear finally to be getting solved, I think it would still be good to create an explicit policy describing the (default) contents of /etc/hostname, /etc/nsswitch.conf and /etc/hosts. The policy should also describe how applications are expected to interpret the contents of these files. Policy should take into account the fact that some computers are not connected to a network; some are connected to the Internet and have a static IP address; some get an IP address via DHCP; some of the latter also get assigned a FQDN. Obviously, applications should work correctly under all circumstances.

I'd agree that having a formal policy for this (presuming there isn't one already, buried somewhere) is an excellent idea. The Debian folks have the Debian Policy Manual, and *everyone* abides by it. The clarity that that approach provides would certainly be welcome here.

Looking through this again, while I agree there might be a need to clarify the way that the fqdn, /etc/hostname and /etc/hosts files and such are being used, this is not a bug in NetworkManager and as far as I am concerned, NM is doing what it should (and so is netcfg, but I'll let Colin close that one if he wants to).

The documentation on what hostname is reporting and why is available on all systems via the 'man hostname' command, with extra information in the manual pages for dnsdomainname; and the implementation is further defined in getdomainname(2) and getaddrinfo(3). The jist of it: if you're using NIS/YP, it's a different matter, but if you're using DNS, you can change what will appear to be the domain name via /etc/hosts (and the value is set there by the installer or modified by the admin, which is the right thing to do) for the 'hostname -f' call, but ultimately the real FQDN is what the resolver returns for the IP address -- that's external to the machine, you can't change it with any local configuration file.

We've covered why NM will not be changing /etc/hosts from DHCP results in bug 659817. TL;DR: it's Very Wrong (tm).

I'm closing the NetworkManager task for this as "Invalid", hopefully we can now lay this to rest for all eternity :)

I am going to be so bold as to close this bug report. The original report (from 2004) and followups reflect the way Ubuntu was installed and what NetworkManager and other software did a long time ago and the subsequent discussion is not clearly about any one issue. If there are still outstanding issues related to this report I would suggest opening a new report with a clear title and description, with references back to this report where appropriate.