Seeing errors like this too:

Sep  6 14:48:29 dsm rpc.yppasswdd[12874]: crypt() call failed.
Sep  6 14:48:29 dsm rpc.yppasswdd[12874]: update user (uid=xxxx) from host xx.xx.xx.xx rejected
Sep  6 14:48:29 dsm rpc.yppasswdd[12874]: Invalid password.

Hi Robert, thanks for reporting this.

Unfortunately I have no idea what "Error #-3" means either, will look into the issue.

(In reply to Petr Kubat from comment #2)
> Hi Robert, thanks for reporting this.
> 
> Unfortunately I have no idea what "Error #-3" means either, will look into
> the issue.

I'm starting to think it's either firewalld or rpc.idmapd failings to initialize libnfsidmap as in https://bugzilla.redhat.com/show_bug.cgi?id=1478129

Here's our firewall-cmd --list-all
public
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: ssh mdns dhcpv6-client nfs mountd smtp https http rpc-bind dns samba samba-client
  ports: 944/tcp 945/tcp 945/udp 946/udp
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

Then rpcinfo -p localhost
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  58498  status
    100024    1   tcp  33419  status
 600100069    1   udp    945  fypxfrd
    100004    2   udp    834  ypserv
 600100069    1   tcp    945  fypxfrd
    100004    1   udp    834  ypserv
    100004    2   tcp    838  ypserv
    100009    1   udp    946  yppasswdd
    100004    1   tcp    838  ypserv
    100007    2   udp    840  ypbind
    100007    1   udp    840  ypbind
    100007    2   tcp    843  ypbind
    100007    1   tcp    843  ypbind
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100021    1   udp  40006  nlockmgr
    100021    3   udp  40006  nlockmgr
    100021    4   udp  40006  nlockmgr
    100021    1   tcp  40995  nlockmgr
    100021    3   tcp  40995  nlockmgr
    100021    4   tcp  40995  nlockmgr

However from the slave server /usr/lib64/yp/ypinit -s IP_of_master
Can't enumerate maps from IP_of_master. Please check that it is running.

Stopping firewalld and all's well.

Are there other custom xml files needed to be created in  /usr/lib/firewalld/services/?

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Still seeing this in Fedora 32
Aug 31 13:49:46  ypserv[3482940]: ypproc_match_2 from x.x.x.x port 46312
Aug 31 13:49:46  ypserv[3482940]: #011#011domainname = "xxx"
Aug 31 13:49:46  ypserv[3482940]: #011#011mapname = "hosts.byname"
Aug 31 13:49:46  ypserv[3482940]: #011#011keydat = "fedoraproject.org"
Aug 31 13:49:46  ypserv[3482940]: connect from x.x.x.x port 46312 to procedure ypproc_match (xxx,hosts.byname;1)
Aug 31 13:49:46  ypserv[3482940]: #011ypdb_open("xxx", "hosts.byname")
Aug 31 13:49:46  ypserv[3482940]: Found: xxx/hosts.byname (8)
Aug 31 13:49:46  ypserv[3482940]: ypdb_close() called
Aug 31 13:49:46  ypserv[3482940]: #011-> Error #-3

On Fedora 34 from journalctl -g pam -xe I see lots of:
Sep 18 08:19:21 ypserv[282972]: #011#011keydat = "pam_unix_non_existent:"

From systemctl status ypserv with -d on restart:
Sep 20 13:25:23 ourdomain.edu ypserv[282972]:         ypdb_open("ourdomain", "hosts.byname")
Sep 20 13:25:23 ourdomain.edu ypserv[282972]: Found: ourdomainh/hosts.byname (8)
Sep 20 13:25:23 ourdomain.edu ypserv[282972]: ypdb_close() called
Sep 20 13:25:23 ourdomain.edu ypserv[282972]:         -> Error #-3

sample from  /var/log/messages
Sep 20 13:38:13 ypserv[282972]: ypproc_match_2 from x.x.x.x port 34923
Sep 20 13:38:13 ypserv[282972]: #011#011domainname = "ourdomain"
Sep 20 13:38:13 ypserv[282972]: #011#011mapname = "hosts.byname"
Sep 20 13:38:13 ypserv[282972]: #011#011keydat = "incoming.telemetry.mozilla.org"
Sep 20 13:38:13 ypserv[282972]: connect from 150.108.64.56 port 34923 to procedure ypproc_match (ourdomain,hosts.byname;1)
Sep 20 13:38:13 ypserv[282972]: #011ypdb_open("ourdomain", "hosts.byname")
Sep 20 13:38:13 ypserv[282972]: Found: ourdomain/hosts.byname (9)
Sep 20 13:38:13 ypserv[282972]: ypdb_close() called
Sep 20 13:38:13 ypserv[282972]: #011-> Error #-3

Can this be looked at again?

Hi,

I took a look a this and here are few things that I manage to find out:

Firstly, let's try to check what this Error #-3 is. That should be quite easy with debug messages provided by you.
Quick search and we can find those debug messages here: https://github.com/thkukuk/ypserv/blob/bccf93bb882a049d1817035cfcee83816947be47/ypserv/server.c#L177
This error message comes from line: 275 and that means that '-3' corresponds to YP_NOKEY constant.
Let's check that: https://github.com/deplinenoise/amiga-sdk/blob/master/netinclude/rpcsvc/yp.x#L20
That's seems correct, so this 'Error' is not an actual error but just information that:
incoming.telemetry.mozilla.org key is not present in /etc/hosts file.

> The key and value pairs (also known as records) that are created from the entries in the/etc/hosts file comprise the hosts.byname map

I think that you shouldn't worry about this error unless that record should be there but
I would check locally first to confirm if that's the case.

Regarding 'pam_unix_non_existent' string in the logs. This is a result of fixing potential loophole that allowed to
determine existence of user. More information about this issue here: https://github.com/linux-pam/linux-pam/commit/30fdfb90d9864bcc254a62760aaa149d373fd4eb
Basically to block potential attacker from using that function to determine 'if users exists' by analyzing
time execution, fake/real iteration was added which prevents attacker from using that loophole.

That's why in your logs you can see 'pam_unix_non_existent'. This is a fake, non-existent account name that is used in 2nd iteration (in your case).

(In reply to mkulik from comment #8)
> Hi,
> 
> I took a look a this and here are few things that I manage to find out:
> 
> Firstly, let's try to check what this Error #-3 is. That should be quite
> easy with debug messages provided by you.
> Quick search and we can find those debug messages here:
> https://github.com/thkukuk/ypserv/blob/
> bccf93bb882a049d1817035cfcee83816947be47/ypserv/server.c#L177
> This error message comes from line: 275 and that means that '-3' corresponds
> to YP_NOKEY constant.
> Let's check that:
> https://github.com/deplinenoise/amiga-sdk/blob/master/netinclude/rpcsvc/yp.
> x#L20
> That's seems correct, so this 'Error' is not an actual error but just
> information that:
> incoming.telemetry.mozilla.org key is not present in /etc/hosts file.
> 
> > The key and value pairs (also known as records) that are created from the entries in the/etc/hosts file comprise the hosts.byname map

OK perhaps the title of this bug should be a feature request to change the wording from "Error #-3" to something more informative like "Error #-3, domain is not in /etc/hosts" but perhaps that isn't quite right as that could be thousands of domains? 

> I think that you shouldn't worry about this error unless that record should
> be there but
> I would check locally first to confirm if that's the case.

Well there is a log that indicates an IP that is definitely in /etc/hosts (obfuscated but you get the point):

Sep 27 14:11:07 ourhost ypserv[527368]: connect from 150.108.x.y port 52652 to procedure ypproc_match (ournisdomain,hosts.byname;1)
Sep 27 14:11:07 ourhost ypserv[527368]: #011ypdb_open("ournisdomain", "hosts.byname")
Sep 27 14:11:07 ourhost ypserv[527368]: Found: ournisdomain/hosts.byname (5)
Sep 27 14:11:07 ourhost ypserv[527368]: ypdb_close() called
Sep 27 14:11:07 ourhost ypserv[527368]: #011-> Error #-3


> Regarding 'pam_unix_non_existent' string in the logs. This is a result of
> fixing potential loophole that allowed to
> determine existence of user. More information about this issue here:
> https://github.com/linux-pam/linux-pam/commit/
> 30fdfb90d9864bcc254a62760aaa149d373fd4eb
> Basically to block potential attacker from using that function to determine
> 'if users exists' by analyzing
> time execution, fake/real iteration was added which prevents attacker from
> using that loophole.
> 
> That's why in your logs you can see 'pam_unix_non_existent'. This is a fake,
> non-existent account name that is used in 2nd iteration (in your case).

Thanks for the explanation of both. Perhaps others will benefit if/when they land here from a search.

FWIW, some users are recommending to block the Firefox telemetry, i.e., "phone home": https://forum.mxlinux.org/viewtopic.php?t=57301

Forgot to mention a separate issue not sure if it's deserving of it's own entry but we also see this error even though SELinux is disabled:
setsebool: Could not change active booleans: Invalid boolean

I'm not sure but setsebool was already fixed in ypbind and It will be included with next release. If the same issue is present but for ypserv package, a new bug should be created for it.

Regarding this -3 error. It shows you (ofc that depends on configuration) that NIS client connected to your NIS server and it want's to performs a key lookup for: incoming.telemetry.mozilla.org.
Map file is present on server but lookup failed because key is not present.

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 37 entered end-of-life (EOL) status on None.

Fedora Linux 37 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.