RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1766944 - Hostname not configured through reverse-DNS query
Summary: Hostname not configured through reverse-DNS query
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Vladimir Benes
Marc Muehlfeld
URL:
Whiteboard:
: 1766945 (view as bug list)
Depends On:
Blocks: 1766945 1875967 1894575 1903942
TreeView+ depends on / blocked
 
Reported: 2019-10-30 10:41 UTC by Renaud Métrich
Modified: 2023-03-24 15:49 UTC (History)
26 users (show)

Fixed In Version: NetworkManager-1.30.0-0.7.el8
Doc Type: Bug Fix
Doc Text:
.NetworkManager now tries to retrieve the host name using DHCP and reverse DNS lookups on all interfaces Previously, if the host name was not set in the `/etc/hostname` file, NetworkManager tried to obtain the host name using DHCP or a reverse DNS lookup only through the interface with the default route with the lowest metric value. As a consequence, it was not possible to automatically assign a host name on networks without a default route. This update changes the behavior, and NetworkManager now first tries to retrieve the host name using the default route interface. If this process fails, NetworkManager tries other available interfaces. As a result, NetworkManager tries to retrieve the host name using DHCP and reverse DNS lookups on all interfaces if it is not set in `/etc/hostname`. To configure that NetworkManager uses the old behavior: . Create the `/etc/NetworkManager/conf.d/10-hostname.conf` file with the following content: + ---- [connection-hostname-only-from-default] hostname.only-from-default=1 ---- . Reload the `NetworkManager` service: + ---- # systemctl reload NetworkManager ----
Clone Of:
Environment:
Last Closed: 2021-05-18 13:29:37 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Renaud Métrich 2019-10-30 10:41:07 UTC
Description of problem:

When configuring the network interface using DHCP and not having any static hostname, NetworkManager sets the hostname from Option 12 (Hostname) and falls back to reverse-DNS query.
However, the reverse-DNS query is not made if there is no default route (typical scenario: isolated network):

src/nm-policy.c:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
 697 static void
 698 update_system_hostname (NMPolicy *self, const char *msg)
 699 {
  :
 821         if (!priv->default_ac4 && !priv->default_ac6) {
 822                 /* No best device; fall back to the last hostname set externally
 823                  * to NM or if there wasn't one, 'localhost.localdomain'
 824                  */
 825                 _set_hostname (self, priv->orig_hostname, "no default device");
 826                 return;
 827         }
  :
 837         /* No configured hostname, no automatically determined hostname, and no
 838          * bootup hostname. Start reverse DNS of the current IPv4 or IPv6 address.
 839          */
 840         device = get_default_device (self, AF_INET);
 841         ip4_config = device ? nm_device_get_ip4_config (device) : NULL;
 842 
 843         device = get_default_device (self, AF_INET6);
 844         ip6_config = device ? nm_device_get_ip6_config (device) : NULL;
 845 
 846         if (   ip4_config
 847             && (addr4 = nm_ip4_config_get_first_address (ip4_config))) {
 848                 g_clear_object (&priv->lookup.addr);
 849                 priv->lookup.addr = g_inet_address_new_from_bytes ((guint8 *) &addr4->address,
 850                                                                    G_SOCKET_FAMILY_IPV4);
  :
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

In the code excerpt above, on line 821, a test is made whether there is some default route, which isn't the case.
This leads to setting hostname to "localhost.localdomain".

When a default route is set, then the code on line 846 and later is used instead, which ends up having a reverse lookup.


Version-Release number of selected component (if applicable):

NetworkManager-1.18.0-5.el7_7.1


How reproducible:

Always


Steps to Reproduce:

1. Install a KVM with 2 networks, 1 (eth1) being isolated

# cat > /etc/sysconfig/network-scripts/ifcfg-eth1 << EOF
TYPE="Ethernet"
BOOTPROTO="static"
DEFROUTE="no"
IPV6INIT="no"
NAME="eth1"
DEVICE="eth1"
ONBOOT="yes"
IPADDR=10.0.0.1
PREFIX=24
EOF

2. Set up a DHCP server on eth1 using dnsmasq that doesn't reply to Option 12 (Hostname) nor Option 3 (Routers) and a static lease for a client

# yum -y install dnsmasq
# cat > /etc/dnsmasq.d/dhcp.conf << EOF
domain=example.com
dhcp-range=10.0.0.100,10.0.0.250,72h
dhcp-host=52:54:00:03:f8:3b,10.0.0.100,FOO7,30d
dhcp-option=3
dhcp-option=12
EOF
# systemctl restart dnsmasq

3. Reconfigure a client VM (MAC 52:54:00:03:f8:3b above) to use the isolated network and remove static hostname

# rm /etc/hostname
# dracut -f

4. Reboot


Actual results:

FQDN Hostname set to "localhost.localdomain"


Expected results:

FQDN Hostname set to "FOO7.example.com"


Additional info:

If "dhcp-option=3" (Routers) is removed from dnsmasq, the client VM gets "FOO7" hostname.

IMHO, the current order of precedence is a bug:
1) a configured hostname (from settings)
2) automatic hostname from the default device's config (DHCP, VPN, etc)
3) the last hostname set outside NM
4) reverse-DNS of the best device's IPv4 address

It should be:
1) a configured hostname (from settings)
2) automatic hostname from the default device's config (DHCP, VPN, etc)
3) reverse-DNS of the best device's IPv4 address
4) the last hostname set outside NM

Or order kept as is but "3) the last hostname set outside NM" be a fallthrough if there was no "last hostname set outside NM", i.e. "localhost".

Comment 2 Antonio Cardace 2020-02-11 14:54:37 UTC
Postponing to RHEL 8.3 as this is quite a big change and needs further discussion regarding which policy to adopt in case there is more than one active device each with its set of nameservers.

Comment 3 Benjamin Schmaus 2020-02-13 18:07:34 UTC
There also appears to be a need for the DHCP server to pass out a default gateway as well.  Our DHCP server was passing out reserved IP addresses and the DNS A and PTR records for host existed however the hostname was ignored and the host ended up with localhost.localdomain.  Once we added the option router to our dhcpd.conf the host picked up the proper hostname.

Comment 4 Thomas Haller 2020-04-07 14:53:01 UTC
*** Bug 1766945 has been marked as a duplicate of this bug. ***

Comment 8 David Lee 2020-10-22 14:13:38 UTC
When we opened this, just over a year ago now, it was for RHEL7. 

We realise that there is unlikely to be a fix for RHEL7.  (We have developed a partial workaround, which is just about good enough for us, although not ideal.) 

But we are now planning our RHEL8 rollout.  Please could you give us an update on the progress you have made, and your estimated date for when we can expect the fix for RHEL8.  Thanks.

-- David Lee
-- Diamond Light Source, UK

Comment 9 Renaud Métrich 2020-10-26 11:25:25 UTC
I'm setting Needinfo on the developer, I have no idea why this doesn't move forward.

Comment 10 Beniamino Galvani 2020-10-26 18:24:40 UTC
Hi, this is planned for RHEL 8.4.

Comment 12 Beniamino Galvani 2020-11-03 13:54:19 UTC
Hi Renaud and David,

I have created a merge request that adds some properties to
NetworkManager connection profiles to control how the hostname is
assigned. The new properties are

 hostname.priority
 hostname.from-dhcp
 hostname.from-dns-lookup
 hostname.only-from-default

Setting the last property to FALSE for a specific connection, the
hostname (from DHCP or reverse DNS lookup) will be used even if the
connection doesn't have the default route. The property can be also
set globally for all connections, for example adding a configuration
file /etc/NetworkManager/conf.d/10-hostname.conf containing:

 [connection]
 hostname.only-from-default=0

If there are multiple connections active, NetworkManager first tries
the connection that was activated first. The order of evaluation can
be changed using the hostname.priority property.

What do you think? Would this solve your issue?

Comment 13 Renaud Métrich 2020-11-05 13:15:26 UTC
Great, that would work I guess.

Comment 14 David Lee 2020-11-05 13:58:10 UTC
Beniamino: Many thanks for picking this up.

I don't know the insides of NetworkManager, so cannot really comment on the detail.

Keep in mind our original bug report, which is specifically about a kickstart environment.  Does your proposed fix cover that?

Our context is a kickstart environment, where (presumably) very little user-adjustable NetworkManager configuration is available.  We had two networks which we were expecting to behave the same way: namely, for the host being installed to pick up its hostname from DHCP.  But this fails consistently on one of those networks (and works consistently on the other).  Even to understand the problem, we were forced to resort to network tracing.  What we discovered was that the host being kickstarted responded differently in a highly unexpected way to the DHCP information it received:

 *  where things worked (i.e. the host being kickstarted correctly got the hostname) the DHCP information contained a default route;
 *  where things failed (i.e. the host being kickstarted did not get its hostname) the DHCP information did not contain a default route

In both cases, the incoming DHCP information contained the hostname.  But the kickstart process fails to act on it when the DHCP information does not contain a default route.

(We did a proof-of-concept check: for the failing "no default route" network, we briefly added a "default route" at the DHCP server, and that fixed it.  But we cannot make that our solution because, for local operational reasons, although we run the two DHCP networks as similarly as possible, this difference in presence/absence of giving a default route is an essential difference.  We must run with this difference.)

Summary:

Our bug report relates to kickstart.  We found that DHCP hostname is ignored when the DHCP information legitimately has no "default route".  We believe this is a bug in the kickstart process, because the hostname is honoured when "default route" is present in the DHCP information.

 
So our requirement, as in the original bug report, is that kickstart should use the hostname regardless of the presence or absence of the "default route".  We would need any fix to be workable in a kickstart environment: either as default behaviour, or at least as a configurable option.  If the latter, then the fix should also include the relevant update to kickstart documentation.

I hope that helps.

Comment 15 David Lee 2020-11-19 09:16:03 UTC
I see this is now marked as "Fixed In Version: NetworkManager-1.30.0-0.3.el8".  Thank you.

Please could you confirm that the kickstart environment is also fixed by this.  That is, that its algorithm follows the same pattern for host-name determination regardless of the presence or absence of default-route in the earlier DHCP response.

If the different behaviour persists by default (why would it?) please could you outline what steps a site will need to take in its kickstart set-up to get the hostname behaviour the same.  (For instance, could you let me see the proposed addition to the kickstart documentation.)

Thanks.

Comment 16 Beniamino Galvani 2020-11-20 16:05:12 UTC
Hi David,

sorry but I missed your comment 14.

With the new properties, NetworkManager can be configured to honor the
hostname from DHCP from all connections (with or without the default
route). For backwards compatibility reasons, however this behaviour is
not the default.

What is needed in your case is to have the
'hostname.only-from-default' property globally set to '0' in a
[connection] section of /etc/NetworkManager/NetworkManager.conf or in
a configuration snippet inside 'conf.d/'. However, since you need the
hostname during installation, this property must be set before NM is
started in the installation boot.

I am not that familiar with kickstart, so let's ask to the installation
team.

Radek, do you think one of the following approaches is feasible in a
kickstart file?

1) if possible, let the kickstart update NM configuration before NM is
started

2) if solution 1) is not possible, then the kickstart should update
the NM configuration, make NM aware of it by reloading the service
("systemctl reload NetworkManager") and then reactivate the
connection.

Thanks

Comment 20 Radek Vykydal 2020-11-30 15:29:20 UTC
(In reply to Beniamino Galvani from comment #16)
> Hi David,
> 
> sorry but I missed your comment 14.
> 
> With the new properties, NetworkManager can be configured to honor the
> hostname from DHCP from all connections (with or without the default
> route). For backwards compatibility reasons, however this behaviour is
> not the default.
> 
> What is needed in your case is to have the
> 'hostname.only-from-default' property globally set to '0' in a
> [connection] section of /etc/NetworkManager/NetworkManager.conf or in
> a configuration snippet inside 'conf.d/'. However, since you need the
> hostname during installation, this property must be set before NM is
> started in the installation boot.
> 
> I am not that familiar with kickstart, so let's ask to the installation
> team.
> 
> Radek, do you think one of the following approaches is feasible in a
> kickstart file?
> 
> 1) if possible, let the kickstart update NM configuration before NM is
> started

This could be eventually done by installer boot option (something like inst.nm.hostname.only-from-default). As a global modification of installer environment this does not seem to belong to kickstart.
Also it would apply only to devices/connections configured by kickstart after switch root (NM activating connections in initramfs would be unaffected in this respect).

> 
> 2) if solution 1) is not possible, then the kickstart should update
> the NM configuration, make NM aware of it by reloading the service
> ("systemctl reload NetworkManager") and then reactivate the
> connection.

This seems to me like a too fragile solution having potential to break common use cases.
May be actually applied by doing this via %pre section kickstart script[1], eg with nmcli command ?

[1] https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#chapter-4-pre-installation-script

Comment 23 zixchen 2020-12-11 10:38:16 UTC
Hi, 

I am virt QE, NetworkManager-1.30.0-0.3.el8.x86_64 introduces a difference, that is hostname is localhost.localdomain when start a VM with default network setting.

I tried to add the following setting in /etc/NetworkManager/NetworkManager.conf, but still got the hostname localhost.localdomain.
[connection]
hostname.only-from-default=0

My expectation is to get hostname from DHCP or reverse DNS lookup, like dhcp183-227.ml3.eng.bos.redhat.com. Could you please to help what else should I do?

Comment 28 zixchen 2020-12-15 08:39:43 UTC
Thanks all, NetworkManager-1.30.0-0.4.el8.x86_64 solve my problem.

Host/guest version:
NetworkManager-1.30.0-0.4.el8.x86_64

Steps:
1. Update NetworkManager-1.30.0-0.4.el8.x86_64 on the host
2. Install a VM
3. login to VM, the hostname is still localhost, update NetworkManager on the guest
4. Reboot the guest
5. login to guest, and hostname is resolved to dhcp183-70.

Actual result:
Hostname resolved to dhcp183-70 on the guest.

Expected result:
Same as above.

Comment 34 David Lee 2020-12-16 09:16:16 UTC
Referring to @xichen 15/Dec/2020:

As I read it, this doesn't look sufficient.  It doesn't seem to demonstrate solving the original bug.  What is needed is that the hostname can be determined during the kickstart process.

Let's backtrack:

  *  If DHCP offers default route, then the kickstart process requests the hostname and this is available throughout the kickstart process.
  *  BUT... and here's the bug... if DHCP does not offer default route, then the kickstart process does not request the hostname and is unable to know the hostname.

IN THIS CONTRAST LIES THE BUG.

The required fix is that the kickstart process requests the hostname in BOTH the above instances.

Xichen's comment was about updating NetworkManager AFTER the installation had already been done

But the bug report is about ensuring (presumably) that the NM downloaded in those earliest stages of kickstart requests the hostname.

A suitable demonstration would be:

  * reproduce the above problem (including the bug-difference between default-route and non-default-route environments; Xichen's comment seems to show that
  * adjust the kickstart download to include the new NM, and now demonstrate that both environments (default-route and non-default-route:  Xichen's comment doesn't include this

Thanks for your work on this.  I hope this helps.

-- David Lee

Comment 36 zixchen 2020-12-16 11:22:59 UTC
Hi David,




I noticed the compose RHEL-8.4.0-20201215.d.2 is out, so test again. The result is hostname is resolved after reboot of the installation, but in post-installation the hostname is still be localhost.localdomain.

Version:
NetworkManager-1.30.0-0.4.el8.x86_64


Steps and details:
1. Add below configurations in /etc/NetworkManager/NetworkManager.conf

[connection]
hostname.priority=1
hostname.from-dhcp=1
hostname.from-dns-lookup=1
hostname.only-from-default=0

2. In my kickstart cfg, network setting is network --bootproto=dhcp, and in my case it has default route.
3. In my post-installation script, I try to fetch hostname, and find out it is localhost.localdomain. In my previous test log, for example with NetworkManager-1.30.0-0.2.el8.x86_64, it can fetch hostname like dhcp180-243.ml3.eng.bos.redhat.com. I am not sure this difference is bug or not.
4. I logged in to the guest, hostname dhcp182-88 is resolved.

(In reply to David Lee from comment #34)
> Referring to @xichen 15/Dec/2020:
> 
> As I read it, this doesn't look sufficient.  It doesn't seem to demonstrate
> solving the original bug.  What is needed is that the hostname can be
> determined during the kickstart process.
> 
> Let's backtrack:
> 
>   *  If DHCP offers default route, then the kickstart process requests the
> hostname and this is available throughout the kickstart process.
>   *  BUT... and here's the bug... if DHCP does not offer default route, then
> the kickstart process does not request the hostname and is unable to know
> the hostname.
> 
> IN THIS CONTRAST LIES THE BUG.
> 
> The required fix is that the kickstart process requests the hostname in BOTH
> the above instances.
> 
> Xichen's comment was about updating NetworkManager AFTER the installation
> had already been done
> 
> But the bug report is about ensuring (presumably) that the NM downloaded in
> those earliest stages of kickstart requests the hostname.
> 
> A suitable demonstration would be:
> 
>   * reproduce the above problem (including the bug-difference between
> default-route and non-default-route environments; Xichen's comment seems to
> show that
>   * adjust the kickstart download to include the new NM, and now demonstrate
> that both environments (default-route and non-default-route:  Xichen's
> comment doesn't include this
> 
> Thanks for your work on this.  I hope this helps.
> 
> -- David Lee


Hi David,

I guess you are needing info from me, my email is zixchen. I noticed the compose RHEL-8.4.0-20201215.d.2 is out now, so test it again. The result is hostname is resolved after reboot of the installation, but in post-installation the hostname is still be localhost.localdomain.

Version:
NetworkManager-1.30.0-0.4.el8.x86_64


Steps and details:
1. Add below configurations in /etc/NetworkManager/NetworkManager.conf

[connection]
hostname.priority=1
hostname.from-dhcp=1
hostname.from-dns-lookup=1
hostname.only-from-default=0

2. In my kickstart cfg, network setting is network --bootproto=dhcp, and in my case it has default route.
3. In my post-installation script, I try to fetch hostname, and find out it is localhost.localdomain. In my previous test log, for example with NetworkManager-1.30.0-0.2.el8.x86_64, it can fetch hostname like dhcp180-243.ml3.eng.bos.redhat.com. I am not sure this difference is bug or not.
4. I logged in to the guest, hostname dhcp182-88 is resolved.

Comment 37 Beniamino Galvani 2020-12-16 12:48:35 UTC
(In reply to David Lee from comment #34)
>   *  If DHCP offers default route, then the kickstart process requests the
> hostname and this is available throughout the kickstart process.
>   *  BUT... and here's the bug... if DHCP does not offer default route, then
> the kickstart process does not request the hostname and is unable to know
> the hostname.
> 
> IN THIS CONTRAST LIES THE BUG.

Hi, you are right, the current fix isn't enough yet to cover the
original bug. As mentioned previously, we believe that allowing NM to
obtain by default the hostname (via DHCP or DNS lookup) from any
interface without default route would be a big change in behavior with
a potential to break existing users.

The idea is to make this configurable in NM and then have a way to
enable the new behavior during installation. The work done so far is
about the NM part.

In comments 16 and 20 there are some proposals on how to enable
the new behavior. I didn't manage to investigate them, but I plan to do
that once the NM part is working properly.

Comment 38 David Lee 2020-12-16 14:17:07 UTC
Beiamino:  Many thanks for your reply.

//we believe that allowing NM to obtain by default the hostname (via DHCP or DNS lookup) from any interface without default route would be a big change in behavior with a potential to break existing users.//

Well, yes, I suppose it might be termed a change to behaviour.  But it is not a change to documented behaviour,  (Is it?)   It is a a bug fix, surely.  There is already a problem in that the discrepancy of behaviour (bug) between "default route" and "non default route" affecting hostname is not documented.  So, yes, technically a change to behaviour.  But, no, not a change to documented behaviour.


//Potential to break existing users.//  Well if existing users of a product (any product) are relying on a bug, then, yes, a bugfix will break it.  But that's in the nature of bugs and their later fixes!  (As programmers, we very rarely say "we won't fix the bug for the future because it might impact a few users who have specifically relied on the bug (and an undocumented bug at that) in the past.")

If the bug is to be preserved, then at the very least, documentation should be written.  If the existing difference is to be maintained, then documentation should state both (a) that there is a difference (b) why this difference is continuing to be positively maintained.

And the very act of attempting such documentation ("hostname is treated differently depending on presence/absence of 'default route' because...") might prompt a rethink!

My own vote would be that, having introduced this new configurability (thank you!), you then make the default hostname behaviour the same irrespective of presence/absence of 'default route', and that the documentation can say with great simplicity "this is how to get/stop hostname behaviour" without having to mention 'default route' at all.  Clean and simple.

Thanks for explaining that this is a two step process (a) adding capability to NM (b) providing hooks into kickstart to drive that capability.  That's useful to know!  I look forward to progress.

-- David Lee

Comment 42 Beniamino Galvani 2021-01-18 15:42:18 UTC
After some discussion, we decided to do:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/92c494f2904c981842192d3eea7b74501c1fda0a

to change the default value of `hostname.only-from-default` to false. In this way NM will get the hostname via DHCP/DNS even without a default route.

Comment 44 David Lee 2021-01-20 10:39:05 UTC
Beiamino:

Many thanks for your thought and work on this.  If I understand your description correctly, this sounds good and promising.  Thank you.

-- David Lee

Comment 53 Beniamino Galvani 2021-01-26 16:11:14 UTC
Hi,

here:

 Jan 26 09:56:01 NetworkManager[830]: <trace> [1611672961.0474] device[fd260e66f3d91440] (eth0): hostname-from-dns: ipv4 resolver state wait-address, old address (null), new address 10.73.115.36
 Jan 26 09:56:01 NetworkManager[830]: <trace> [1611672961.0474] device[fd260e66f3d91440] (eth0): hostname-from-dns: starting lookup for address 10.73.115.36
 Jan 26 09:56:01 NetworkManager[830]: <trace> [1611672961.0476] dns-mgr: current configuration: [{'nameservers': <['10.73.2.107', '10.73.2.108', '10.66.127.10']>, ...

NM tries a reverse DNS lookup of address 10.73.115.36 using
nameservers 10.73.2.107, 10.73.2.108, 10.66.127.10, but there is no
result.

Everything looks correct in this log, except for the lookup result. I
don't know if this is a NM problem or an infrastructure one. Since you
said that other machines are getting the hostname, perhaps you can
grab the trace logs from a working machine, so that we can compare it
with the failing one. Thank you.

Comment 68 errata-xmlrpc 2021-05-18 13:29:37 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: NetworkManager and libnma security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:1574


Note You need to log in before you can comment on or make changes to this bug.