minion id ends with non-existing domain ".mshome.net"

[marbx]

Description of Issue/Question

The domain grain is "mshome.net" which is not correct

This domain appears also in the fqdn

salt-call grains.item domain
local:
    ----------
    domain:
        mshome.net

Setup

Installed 2018.3.4 Py3 on Windows 10.

Versions Report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

salt-call --versions-report

Salt Version:
Salt: 2018.3.4

Dependency Versions:
cffi: 1.10.0
cherrypy: 10.2.1
dateutil: 2.6.1
docker-py: Not Installed
gitdb: 2.0.5
gitpython: 2.1.3
ioflo: Not Installed
Jinja2: 2.9.6
libgit2: Not Installed
libnacl: 1.6.1
M2Crypto: Not Installed
Mako: 1.0.6
msgpack-pure: Not Installed
msgpack-python: 0.4.8
mysql-python: Not Installed
pycparser: 2.17
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 3.5.3 (v3.5.3:1880cb95a742, Jan 16 2017, 16:02:32) [MSC v.1900 64 bit (AMD64)]
python-gnupg: 0.4.1
PyYAML: 3.12
PyZMQ: 16.0.3
RAET: Not Installed
smmap: 2.0.5
timelib: 0.2.4
Tornado: 4.5.1
ZMQ: 4.1.6

System Versions:
dist:
locale: cp1252
machine: AMD64
release: 10
system: Windows
version: 10 10.0.16299 SP0 Multiprocessor Free

[twangboy]

If it's not part of a domain, it will use the workgroup. What is the workgroup setting on this machine?

[marbx]

Which command shall I execute for the workgroup settings?

[marbx]

The Python 2 Minion does show the correct domain.

C:>\salt\salt-call --versions-report
Salt Version:
Salt: 2018.3.4

Dependency Versions:
cffi: 1.10.0
cherrypy: 10.2.1
dateutil: 2.6.1
docker-py: Not Installed
gitdb: 2.0.5
gitpython: 2.1.3
ioflo: Not Installed
Jinja2: 2.9.6
libgit2: Not Installed
libnacl: 1.6.1
M2Crypto: Not Installed
Mako: 1.0.6
msgpack-pure: Not Installed
msgpack-python: 0.4.8
mysql-python: Not Installed
pycparser: 2.17
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:25:58) [MSC v.1500 64 bit (AMD64)]
python-gnupg: 0.4.1
PyYAML: 3.12
PyZMQ: 16.0.3
RAET: Not Installed
smmap: 2.0.5
timelib: 0.2.4
Tornado: 4.5.1
ZMQ: 4.1.6

System Versions:
dist:
locale: cp1252
machine: AMD64
release: 10
system: Windows
version: 10 10.0.16299 Multiprocessor Free

[twangboy]

I would log on to the machine and check the domain settings. Is it connected to a domain? What domain/workgroup name is shown in the GUI?

Windows Key+Break
Advanced System Settings
Computer Name tab

[marbx]

The client is in a domain which is still properly reported in the domain grain of the Python 2 minion.

I will continue to use the Python 2 client.

The grains unit test
does not test any grain value.

For the long term, I suggest that the unit test also covers values, starting with the domain.

The domain name should be in socket.getfqdn()

I can only add a test that is run by Jenkins, or I need to learn how to run the tests locally.

[twangboy]

OK. I'll take a look at it and get some tests written up.

[twangboy]

@markuskramerIgitt Would you mind verifying the above PR?

[twangboy]

@markuskramerlgitt So, there is a grain called windowsdomain. The above PR sets the domain grain to be the same as the windowsdomain grain. But, now that I think about it, the domain grain may refer to a dns domain instead of the windows domain name. It uses socket.get_fqdn to determine the domain name. So, maybe the above PR shouldn't be the fix and you should use the windowsdomain grain instead.
@UtahDave @dwoz What do you think?

[marbx]

Please continue to distinguish
Domain and
Windows domain

[marbx]

I wrongly get "mshome.net" from Salt of Py2, Py3 and directly from socket.getfqdn().

Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)] on win32
>>> import socket
>>> socket.getfqdn()
'**********.mshome.net'

This seems to be a DHCP configuration problem.

[marbx]

As this is not a Salt issue, I close it

[marbx]

The Python issue is https://bugs.python.org/issue36382

[marbx]

I found another client with mshome.net domain.

I guess under some conditions and from the viewpoint of Python, the Hyper-V adapter takes precedence over all other network adapters and therefore mshome.net overrides the network domains of the other adapters.

[marbx]

salt -G 'domain:mshome.net' grains.item ipv4, revealed that ~ 3% of the clients are affected

[marbx]

Still an issue with version 3001 physical minions.

Probably caused when client starts "offline" (cannot initially connect to the salt-master).

workaround exist with minion_id_remove_domain: True from PR #49378