SOLVED On the origin of the “No supported key exchange algorithms” error message of sshd

sshd shuts down with “No supported key exchange algorithms” error; Dmitry Gladkov; in Server Fault; 2010-07-07.

Actualities

us
Feb 23 12:19:36 host.example.com sshd[967]: Server listening on 0.0.0.0 port 22.
Feb 23 12:19:36 host.example.com sshd[967]: Server listening on :: port 22.
Feb 23 12:19:56 host.example.com sshd[1361]: fatal: No supported key exchange algorithms [preauth]

Diagnosis

The ssh host key files are readable by more than merely the owner

Incorrect

$ ls -l /etc/ssh/ssh*key*
-rw-r-----. 1 root root  227 Feb 23 11:56 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r--. 1 root root  162 Feb 23 11:56 /etc/ssh/ssh_host_ecdsa_key.pub
-rw-r-----. 1 root root  387 Feb 23 11:56 /etc/ssh/ssh_host_ed25519_key
-rw-r--r--. 1 root root   82 Feb 23 11:56 /etc/ssh/ssh_host_ed25519_key.pub
-rw-r-----. 1 root root 1675 Feb 23 11:56 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root  382 Feb 23 11:56 /etc/ssh/ssh_host_rsa_key.pub

Correct

$ ls -l /etc/ssh/ssh*key*
-rw-------. 1 root root  227 Feb 23 11:56 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r--. 1 root root  162 Feb 23 11:56 /etc/ssh/ssh_host_ecdsa_key.pub
-rw-------. 1 root root  387 Feb 23 11:56 /etc/ssh/ssh_host_ed25519_key
-rw-r--r--. 1 root root   82 Feb 23 11:56 /etc/ssh/ssh_host_ed25519_key.pub
-rw-------. 1 root root 1675 Feb 23 11:56 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root  382 Feb 23 11:56 /etc/ssh/ssh_host_rsa_key.pub

HOWTO Disable HTML5 Video Autoplay in Firefox

about:config
media.autoplay.enabled = false [default true]

Does not work until Firefox 41:

  • 1242713media.autoplay.enabled=false does not prevent videos on youtube to autostart; In Bugzilla of Mozilla; 2016-01-25→current.; still open.
    tl;dr → describes Firefox 42, on Linux.
  • 659285Extend media.autoplay.enabled to provide a way to disable untrusted play() invocations; In Bugzilla of Mozilla; 2011-04-24→2016-01-25; resolved as fixed.

[SOLVED] rngd: read error, No entropy sources working, exiting rngd

Explanation

<quote>

rngd has three potential sources of randomness:

  • the RdRand instruction present in some x86 CPUs.
  • a system hardware random number generator at /dev/hwrng (not /dev/hwrandom).
  • a trusted platform module at /dev/tpm0

If your CPU doesn’t support RdRand and you don’t have either of those devices, rngd won’t get triggered to start (and if it did, it would fail on startup).

</quote>

Via: commentariat; Shea Levy; In archives of some mailing list; 2012-11-29

Context

Folklore

Actualities

There are enough files...

$ ls -ld /dev/*random* /dev/*rng* /dev/tpm0
ls: cannot access /dev/tpm0: No such file or directory
crw-------. 1 root root 10, 183 Dec 27 17:47 /dev/hwrng
crw-rw-rw-. 1 root root  1,   8 Dec 27 17:47 /dev/random
crw-rw-rw-. 1 root root  1,   9 Dec 27 17:47 /dev/urandom

The daemon attempts to read, but fails and then exits.

Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: read error
Dec 27 18:20:22 server rngd: No entropy sources working, exiting rngd

SOLVED: Diagnosis & remediation for gnome-terminal failure to start with Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error spawning command line ‘dbus-launch…’

Indications

** (gnome-terminal:28588): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-jXttvb928F: Connection refused
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error spawning command line 'dbus-launch --autolaunch=2f24fcda41304c13ac6826ea32e20941 --binary-syntax --close-stderr': Child process exited with code 1

Diagnosis

There are too many connections to he X11 server.

Remediation

Have fewer connections to your X11 server.

Background

The limit is only have ~255 (or maybe it’s 127, unclear). The error messaging when connections to the graphics server fail are … murky and misdirecting at best.

Folklore

Kerberos … something about delegated credentials or DNS-rDNS consistency

Delegated Credential

A delegated credential looks “simple” on the delegated host.

The (Forwarded) Delegated Credential

[as wbaker@remote.example.com]
$ klist
Ticket cache: KEYRING:persistent:500:500
Default principal: wbaker@EXAMPLE.COM

Valid starting       Expires              Service principal
12/20/2015 09:37:41  12/20/2015 16:36:10  krbtgt/EXAMPLE.COM@EXAMPLE.COM

The Origin Credential

Back on the origin host whence the credential came, there are many more principals

[as wbaker@origin.example.com]
$ klist
Ticket cache: DIR::/run/user/500/krb5cc/tkt
Default principal: wbaker@EXAMPLE.COM

Valid starting       Expires              Service principal
12/19/2015 16:36:10  12/20/2015 16:36:10  krbtgt/EXAMPLE.COM@EXAMPLE.COM
12/19/2015 16:36:14  12/20/2015 16:36:10  nfs/pickle.department.example.com@EXAMPLE.COM
12/19/2015 16:36:19  12/20/2015 16:36:10  nfs/steeple.department.example.com@EXAMPLE.COM
12/19/2015 16:37:30  12/20/2015 16:36:10  nfs/tagger.department.example.com@EXAMPLE.COM
12/19/2015 16:37:33  12/20/2015 16:36:10  nfs/badmouth.department.example.com@EXAMPLE.COM
12/19/2015 18:35:45  12/20/2015 16:36:10  host/munchy.department.example.com@EXAMPLE.COM
12/20/2015 05:42:22  12/20/2015 16:36:10  nfs/bopple.department.example.com@EXAMPLE.COM
12/20/2015 07:14:31  12/20/2015 16:36:10  host/flowerpot.department.example.com@EXAMPLE.COM
12/20/2015 07:57:49  12/20/2015 16:36:10  host/acorn.department.example.com@EXAMPLE.COM
12/20/2015 09:47:28  12/20/2015 16:36:10  host/welcome.department.example.com@EXAMPLE.COM
12/20/2015 10:19:03  12/20/2015 16:36:10  host/ravenswood.department.example.com@EXAMPLE.COM
12/20/2015 10:55:29  12/20/2015 16:36:10  host/capstone.department.example.com@EXAMPLE.COM

Updating Delegated Credentials

If GSSAPI Authentication is configured in OpenSSH client and server, then this “just works.” GSSAPI Authentication is on for server side in default configuration on Fedora. See /etc/ssh/sshd_config.

Forwarding Delegated Credentials
$ ssh -v -v capstone date 2>&1 | grep Delegating
debug1: Delegating credentials
debug1: Delegating credentials
~/.ssh/config
Host *
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes
  # trust DNS to canonicalize short names into fqdns (else delegation doesn't happen)
  GSSAPITrustDns yes

Server Configuration

The server is configured appriopriately by default; from openssh-5.8 of Fedora 16 onwards into openssh-7.1of the Fedora 23 era.
/etc/ssh/sshd_config
# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

Ignore these, leave them commented out, they pertain to the SSHv1 protocol:

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

Diagnosis & Observation

Correct Delegation

The -K flag is the same as -o GSSAPIAuthentication=yes.

$ ssh -K -v -v -v satellite
<snip/>
debug2: key: /home/wbaker/.ssh/id_ecdsa ((nil)),
debug2: key: /home/wbaker/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Delegating credentials
debug1: Delegating credentialsdebug1: Authentication succeeded (gssapi-with-mic).
Authenticated to satellite ([2001:db8::9876]:22).
debug1: channel 0: new [client-session]

Failure to Delegate

Without -Kor
$ ssh -v -v -v -o GSSAPIAuthentication=no satellite
<snip/>
debug2: key: /home/wbaker/.ssh/id_rsa ((nil)),
debug2: key: /home/wbaker/.ssh/id_dsa ((nil)),
debug2: key: /home/wbaker/.ssh/id_ecdsa ((nil)),
debug2: key: /home/wbaker/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
MISSING Delegating credentials message(s)
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to satellite ([2001:db8::9876]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug1: Requesting authentication agent forwarding.
debug2: channel 0: request auth-agent-req@openssh.com confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0

The Error of Reverse DNS (rDNS) Inconsistency

$ ssh -v -v -v -o GSSAPIAuthentication=yes flowerpot
<snip/>
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Unspecified GSS failure. Minor code may provide more information
Generic error (see e-text)
<blank/>
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
Diagnosis:

The DNS and reverse DNS is not synchronized e.g.
/bin/hostname gives flowerpot.example.com

flowerpot.department.example.com. AAAA 2001:db8::9876:1234
4.3.2.1.6.7.8.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2 PTR flowerpot2.department.example.com.
Note

After correcting the hostname, you do not need to restart sshd. The running sshd will continue to recover the system’s hostname dynamically.

Missing Host Principals

The Error of Reverse DNS (rDNS) Inconsistency

$ ssh -v -v -v -o GSSAPIAuthentication=yes flowerpot
<snip/>
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information 
Server host/flowerpot.department.example.com@EXAMPLE.COM not found in Kerberos database 

debug1: Unspecified GSS failure. Minor code may provide more information 
Server host/flowerpot.department.example.com@EXAMPLE.COM not found in Kerberos database 

debug1: Unspecified GSS failure. Minor code may provide more information 
<blank/>
<blank/>
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
[as wbaker@flowerpot]
$ sudo klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
3 nfs/flowerpot.department.example.com@EXAMPLE.COMThis example is missing host principals for flowerpot.

Remediation: add the host principals.
[as wbaker@flowerpot]
$ sudo kadmin -k wbaker/admin
kadmin: addprinc -randkey host/flowerpot.department.example.com
kadmin: ktadd host/flowerpot.department.example.com
Optionally, if necessary, but probably not necessary
kadmin: addprinc -randkey host/flowerpot.example.com
kadmin: ktadd host/flowerpot.example.com
kadmin: quit
[as wbaker@flowerpot]
$ sudo klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
3 nfs/flowerpot.department.example.com@EXAMPLE.COM
2 host/flowerpot.department.example.com@EXAMPLE.COM
2 host/flowerpot.department.example.com@EXAMPLE.COM
2 host/flowerpot.department.example.com@EXAMPLE.COM
2 host/flowerpot.department.example.com@EXAMPLE.COM
2 host/flowerpot.department.example.com@EXAMPLE.COM
2 host/flowerpot.department.example.com@EXAMPLE.COM
2 host/flowerpot.example.com@EXAMPLE.COM
2 host/flowerpot.example.com@EXAMPLE.COM
2 host/flowerpot.example.com@EXAMPLE.COM
2 host/flowerpot.example.com@EXAMPLE.COM
2 host/flowerpot.example.com@EXAMPLE.COM
2 host/flowerpot.example.com@EXAMPLE.COM

Recall that certain encryption algorithms have to be removed from the keytab on Fedora 18 & prior..

[as wbaker@flowerpot]
$ sudo systemctl restart nfs-secure nfs-idmap sshd

The expectation here is that this is not an NFS server and as such nfs-secure-server is not active, and does not need a restart. Failing to restart both nfs-secure and nfs-secure-server manifests in its own separate set of error (impossibly cryptic) error indications (as segfaults).

[as wbaker@origin]

$ ssh -v -v flowerpot date 2>&1 | grep Delegate
debug1: Delegating credentials
debug1: Delegating credentials

Restarting the GNOME keyring daemon after (it) crashes

tl;dr

setsid /usr/bin/gnome-keyring-daemon > ~/tmp/o.gnome-keyring-daemon.out 2>&1 &
$ cd /run/user/500
$ sudo mount --bind keyring-$NEW keyring-$OLD

Concept

  • Restart the daemon by hand
  • Modify /run/user/$UID to contain the appropriate directory
    • Both the old and the new keyring directories (names) need to “work”
    • Do not use a symlink to get the defunct name to point to the operational one.
      The keyring daemon will observe this after a time and will shut down on its own.
    • Use a bind mount to mount the directory of the operating daemon onto the name of the inoperative one

Background

  • For various reasons gnome-keyring daemon can die
  • You cannot (conveniently) establish a new GNOME session (logout, login again)
  • Many sessions depend upon access to the existing security apparatus
    • ssh-agent
    • gpg-agent
    • etc.

Error Messages

The keyring daemon dies spontaneously:

Dec 28 12:56:08 vast kernel: [2230783.652433] traps: gnome-keyring-d[2679] trap int3 ip:3fd704ed9d sp:7fff617dc420 error:0

If the keyring directory itself is not actually a directory or does not have the correct permissions, then the keyring daemon exits without further recourse:

** Message: Replacing daemon, using directory: /run/user/500/keyring-IIUwlw
** Message: The gnome-keyring control directory has invalid permissions. It must be only be accessible by its owner (ie: 0700): /run/user/500/keyring-IIUwlw

Configuration

  • Fedora 19
  • GNOME 3.8
  • gnome-keyring-3.8.2-1.fc19.x86_64

References

Folklore

  • How to start the keyring daemon after a gnome-shell crash?; Some droid using the self-asserted identity token l0b0; In Stack Exchange; 2012-02-25.
    tl;dr → refers to GNOME circa 2012 (what was that?), but the concepts are valid.
  • GNOME Keyring; In Some Document Landfill; undated.
    tl;dr → seems to have good & current information; sortof, is involved in the GNOME2 & Mate dissent etc.

Actualities

There are too many (user) processes running. In the gnome-keyring-daemon spontaneously exits.

-bash: fork: retry: No child processes
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: retry: No child processes
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: retry: No child processes
-bash: fork: retry: Resource temporarily unavailable
<snip/>
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable

You have to resolve this resource issue before moving in. Perhaps there are to many ssh clients reaching out into the network. Perhaps

$ setsid /usr/bin/gnome-keyring-daemon) > ~/tmp/o.gnome-keyring-daemon.out 2>&1 &
[1] 15202

Restarting the gnome-keyring-daemon results in names on the standard output, which would normally become environment variables for descendants.

GNOME_KEYRING_CONTROL=/run/user/500/keyring-J2oEff
SSH_AUTH_SOCK=/run/user/500/keyring-J2oEff/ssh
GPG_AGENT_INFO=/run/user/500/keyring-J2oEff/gpg:0:1
GNOME_KEYRING_PID=15208
$ cd /run/user/500
$ rm keyring-1Vplme
$ mkdir keyring-1Vplme
$ sudo mount --bind keyring-J2oEff keyring-1Vplme

[SOLVED] Continuing the Bringup of Kerberized NFSv4 on Fedora 16 through Fedora 23

Continued from bringing up Kerberized NFSv4 on Fedora 16 through Fedora 23
Onward as continued, refined & summarized.

tl;dr

  • To make Fedora 17 clients “work,” one must remove nfs host keys encrypted with
    • camellia128-cts-cmac
    • camellia256-cts-cmac
  • To make Fedora 18 servers “work,” one must remove nfs host keys encrypted with
    • camellia128-cts-cmac
    • camellia256-cts-cmac

Also

  • Ensure that /etc/imapd.conf has appropriate definitions for
    • Domain = the domain of the NFS clinet’s address
    • Local-Realms = the Domain and any sibling or ancestor settings

Configuration

Release Packages
Fedora 16 krb5-libs-1.9.4-3.fc16.i686
krb5-workstation-1.9.4-3.fc16.i686
nfs-utils-1.2.5-8.fc16.i686
Fedora 17 krb5-libs-1.10.2-6.fc17.i686
krb5-workstation-1.10.2-6.fc17.i686
nfs-utils-1.2.6-5.fc17.i686
Fedora 18 krb5-libs-1.10.3-17.fc18.i686
krb5-workstation-1.10.3-17.fc18.i686
nfs-utils-1.2.7-6.fc18.i686
Fedora 19 krb5-libs-1.11.3-24.fc19.x86_64
krb5-workstation-1.11.3-24.fc19.x86_64
nfs-utils-1.2.8-6.3.fc19.x86_64
Fedora 20 krb5-libs-1.11.5-19.fc20.x86_64
krb5-workstation-1.11.5-19.fc20.x86_64
nfs-utils-1.3.0-2.4.fc20.x86_64
Fedora 21 krb5-libs-1.12.2-15.fc21.x86_64
krb5-workstation-1.12.2-15.fc21.x86_64
nfs-utils-1.3.1-6.3.fc21.x86_64
Fedora 22 krb5-libs-1.13.1-3.fc22.x86_64
nfs-utils
(some version)
Fedora 23 krb5-libs-1.13.2-13.fc23.x86_64
krb5-workstation-1.13.2-13.fc23.x86_64
nfs-utils-1.3.3-1.rc1.fc23.x86_64

References

Configuration

allow_weak_crypto
defaults to false starting with krb5-1.8. When false, removes single-DES enctypes (and other weak enctypes) from permitted_enctypes, default_tkt_enctypes, and default_tgs_enctypes. Do not set this to true unless the use of weak enctypes is an acceptable risk for your environment and the weak enctypes are required for backward compatibility.
permitted_enctypes
controls the set of enctypes that a service will accept as session keys.
default_tkt_enctypes
controls the default set of enctypes that the Kerberos client library requests when making an AS-REQ. Do not set this unless required for specific backward compatibility purposes; stale values of this setting can prevent clients from taking advantage of new stronger enctypes when the libraries are upgraded.
default_tgs_enctypes
controls the default set of enctypes that the Kerberos client library requests when making a TGS-REQ. Do not set this unless required for specific backward compatibility purposes; stale values of this setting can prevent clients from taking advantage of new stronger enctypes when the libraries are upgraded.

The following per-realm setting in kdc.conf affects the generation of long-term keys.

supported_enctypes
controls the default set of enctype-salttype pairs that kadmind will use for generating long-term keys, either randomly or from passwords.
enctype weak? krb5
des-cbc-crc weak all
des-cbc-md4 weak all
des-cbc-md5 weak all
des3-cbc-sha1 notyet >=1.1
arcfour-hmac notyet >=1.3
arcfour-hmac-exp weak >=1.3
aes128-cts-hmac-sha1-96 notyet >=1.3
aes256-cts-hmac-sha1-96 notyet >=1.3
camellia128-cts-cmac notyet >=1.9
camellia256-cts-cmac notyet >=1.9

Enabling and configuring a static iptables firewall in Fedora 21 (Workstation or Server)

$ sudo yum install -y iptables-services
Loaded plugins: langpacks
Resolving Dependencies
--> Running transaction check
---> Package iptables-services.i686 0:1.4.21-13.fc21 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

====================================================================================================
 Package                    Arch          Version                  Repository                  Size
====================================================================================================
Installing:
 iptables-services          i686          1.4.21-13.fc21           collected-by-file           53 k

Transaction Summary
====================================================================================================
Install  1 Package

Total download size: 53 k
Installed size: 19 k
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction (shutdown inhibited)
  Installing : iptables-services-1.4.21-13.fc21.i686                                            1/1 
warning: /etc/sysconfig/ip6tables created as /etc/sysconfig/ip6tables.rpmnew
warning: /etc/sysconfig/iptables created as /etc/sysconfig/iptables.rpmnew
  Verifying  : iptables-services-1.4.21-13.fc21.i686                                            1/1 

Installed:
  iptables-services.i686 0:1.4.21-13.fc21                                                           

Complete!
$ sudo systemctl enable iptables
Created symlink from /etc/systemd/system/basic.target.wants/iptables.service to /usr/lib/systemd/system/iptables.service.

$ sudo systemctl start iptables
Job for iptables.service failed. See "systemctl status iptables.service" and "journalctl -xe" for details.

Folklore

Diagnosing Gnome Terminal failure to start over ssh from merely the cryptic message: Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Could not connect: Connection refused

tl;dr

The contents of /etc/machine-id was the same on both machines

Remediation

uuidgen | sed -e 's/-//g' | sudo tee /etc/machine-id

Complications

  • Some machine ‘s gnome-terminal “just works”
  • Some machine’s gnome-terminal “fails silently”
  • They are “the same”
    • Same package set
    • Same Fedora 22
    • Same VM
    • Same hosting service
    • VMs created within hours of each other
    • etc.

say that again

Same hosting service, same OS, the VMs created within hours of each other,

Indications

localhost $ ssh -Y server.example.com
remotehost $ gnome-terminal
** (gnome-terminal:4508): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8BIJ2Pi6pY: Connection refused
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Could not connect: Connection refused

Diagnosis

  • The user-level dbus-daemon has not started. Fix that.
  • Someone or some thing is not creating ~/.dbus/session-bus.
  • Someone or some thing is not allowing dbus-launch to do anything at all

Differences

Packages

Recall, that one VM “just works” and one VM exhibits the problem. Of course, both are “the same” being Fedora 22, the same kernel 4.1.5, created within hours of each other, etc. The differences in packages between the two

$ diff o.broken-vm-package.list o.working-vm-package.list
78d77
broken> elfutils-default-yama-scope
422a422
working> python2-firewall
433d432
broken> python-firewall
439d437
broken> python-pip
442d439
broken> python-setuptools

This not indicative of anything.

Machine ID

The Machine IDs of the two machines are “the same” becaues they were created from the same VM cloud image; the Machine ID wasn’t regenerated when the instance was activated.

working.example.com $ ls -lZ /etc/machine*
-r--r--r-- 1 root root ? 33 May 26 09:28 /etc/machine-id
working.exampe.com $ cat /etc/machine-id 
8aed69c9cc314c318b2af5672573b109
failing.example.com $ ls -lZ /etc/machine*
-r--r--r-- 1 root root ? 33 May 26 09:28 /etc/machine-id
failing.example.com$ cat /etc/machine-id.orig
8aed69c9cc314c318b2af5672573b109

Same contents in the files, same (very old) date in on the files; the date pertains to when the cloud VM image was created.

Remediation
uuidgen | sed -e 's/-//g' | sudo tee /etc/machine-id

Unhelpful

  • Did you reboot?
    No, rebooting, whatever that might mean, doesn’t help.
  • You need to start dbus-daemon --session.
    No, that is supposed to be started by dbus-launch, automatically.

References

Free Desktop Documentation

Folklore

Helpful

  • 834347gnome-terminal through ssh session fails because of stale X server property; In Red Hat Bugzilla; 2013-08-06-21 → 2013-08-01.
    tl;dr → filed against Fedora 17, yet was helpful for Fedora 22.
    Suggests: dbus-launch --exit-with-session gnome-terminal
  • dbus-launch – Utility to start a message bus from a shell script; In Free Desktop Documentation
    Describes
  • DBUS_SESSION_BUS_ADDRESS environment variable
  • The --autolaunch behavior
  • Default behavior is as if DBUS_SESSION_BUS_ADDRESS=autolaunch: was set
  • Unclear
    • The behavior when ssh’ing to a remote machine; is vague about what does or should happen.
    • How the ~/.dbus/session-bus/machine-id files get created
    • <quote>If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use D-Bus, by default the process will attempt to invoke dbus-launch with the --autolaunch option to start up a new session bus or find the existing bus address on the X display or in a file in ~/.dbus/session-bus/</quote>

Misdirection

Apparently there are problems with gnome-terminal and locales. This is not that problem.
This is a different issue, not described here.

Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 8

2)

Actualities

You should see two dbus instances

  • dbus-daemon --system
  • dbus-daemon --session
$ ps -ef | grep dbus
dbus      2559     1  0 12:08 ?        00:00:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
wbaker    4749     1  0 13:05 ?        00:00:00 /usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
wbaker    5107  4780  0 13:19 pts/5    00:00:00 grep --color=auto dbus

To be placed in & around the ~/.bash_profile; interesting but unnecessary in modern Fedora.

# set dbus for remote SSH connections
if [ -n "$SSH_CLIENT" -a -n "$DISPLAY" ]; then
    machine_id=$(LANGUAGE=C hostnamectl|grep 'Machine ID:'| sed 's/^.*: //')
    x_display=$(echo $DISPLAY|sed 's/^.*:\([0-9]\+\)\(\.[0-9]\+\)*$/\1/')
    dbus_session_file="$HOME/.dbus/session-bus/${machine_id}-${x_display}"
    if [ -r "$dbus_session_file" ]; then
            export $(grep '^DBUS.*=' "$dbus_session_file")
            # check if PID still running, if not launch dbus
            ps $DBUS_SESSION_BUS_PID | tail -1 | grep dbus-daemon >& /dev/null
            [ "$?" != "0" ] && export $(dbus-launch) >& /dev/null
    else
            export $(dbus-launch) >& /dev/null
    fi
fi

SOLVED: NFSv4 idmap (rpc.idmapper) does not work, with AUTH_SYS, sec=sys, and perhaps never did?

Status

SOLVED, sortof…
tl;dr → the universal recommendation is to use GSS & Kerberos (an unproven technique).

/etc/modprobe.d/nfs.conf (you create this)
options nfs nfs4_disable_idmapping=0
options nfsd nfs4_disable_idmapping=0

The mapping of UID (GID) in NFSv4 with AUTH_SYS, sec=sys can be “made to work” but you have to set module parameters in client & server. The result is a somewhat confusing world where authorization can fail but the reporting shows the mapped identifiers.

Debugging

Something about adding -v -v -v (three levels of verbosity) to RPCIDMAPDARGS in /etc/sysconfig/nfs Establishing verbosity in /etc/idmapd.conf doesn’t seem to have the same effect (or much of any effect beyond level 1).

RPCIDMAPDARGS="-v -v -v"
sudo vi /etc/sysconfig/nfs 
sudo systemctl restart nfs-config
sudo systemctl restart nfs-idmapd

Separately, be sure to configure your system to actually perform the id mappings:

echo N | sudo tee /sys/module/nfs/parameters/nfs4_disable_idmapping
echo N | sudo tee /sys/module/nfsd/parameters/nfs4_disable_idmapping

The service names nfs-idmap and nfs-idmapd (the trailing d in idmap vs idmapd) are synonyms by virtue of a symoblic link.
Under triple-verbose, the nfsidmap does log chatter about name translations when they occur. To wit:

Jul 26 12:47:10 client nfsidmap[13714]: nfs4_name_to_uid: calling nsswitch->name_to_uid
Jul 26 12:47:10 client nfsidmap[13714]: nss_getpwnam: name 'wbaker@example.com' domain 'example.com': resulting localname 'wbaker'
Jul 26 12:47:10 client nfsidmap[13714]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
Jul 26 12:47:10 client nfsidmap[13714]: nfs4_name_to_uid: final return value is 0
Jul 26 12:47:10 client nfsidmap[13716]: key: 0xac3eb81 type: gid value: source@example.com timeout 600
Jul 26 12:47:10 client nfsidmap[13716]: nfs4_name_to_gid: calling nsswitch->name_to_gid
Jul 26 12:47:10 client nfsidmap[13716]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
Jul 26 12:47:10 client nfsidmap[13716]: nfs4_name_to_gid: final return value is 0

Partial Resolution

NFSv4 ID mapping is disabled by default in Fedora 18 through Fedora 21 (and back into Fedora 16 with post-release updated kernels).  Apparently id mapping used to “work” in Fedora 16 (kernel-3.2 & prior). Via: Comment 13, Maurizio Paolini. 2013-04-17
Setting these to ‘Y’ can establish ID mapping behaviors.

client (Fedora 21)

$ cat /sys/module/nfsd/parameters/nfs4_disable_idmapping
Y
$ cat /sys/module/nfs/parameters/nfs4_disable_idmapping
Y

And persistently in /etc/modprobe.d/nfs.conf (you create this):

options nfs nfs4_disable_idmapping=0
options nfsd nfs4_disable_idmapping=0

server (Fedora 18)

$ cat /sys/module/nfsd/parameters/nfs4_disable_idmapping
Y
$ cat /sys/module/nfs/parameters/nfs4_disable_idmapping
cat: /sys/module/nfs/parameters/nfs4_disable_idmapping: No such file or directory

The (pseudo-)file won’t exist if nfs client services aren’t im play.

Problem

Actual

client$ ls -ld /areas/documents
drwxrwsr-x. 33 500 source 4096 Apr 23 06:34 /areas/documents

Expected

client$ ls -ld /areas/documents
drwxrwsr-x. 33 wbaker source 4096 Apr 23 06:34 /areas/documents

Not looking for an authorization effect here, just looking for a reporting effect.  The expectation is that the User IDs would be matched by name and reported appropriately on the client.
Redeclared: this is not the well-known authorization problem of AUTH_SYS and NFSv4.
Re-redeclared: <known>When kerberos is not in use the client now just sends uid/gid pairs for authorization.</known>

Characterization

  • NFSv4 → yes
    • NFSv3 → no
    • NFSv2 → no
  • Authorization
    • AUTH_GSS → no
    • AUTH_KERB → no (Kerberos)
    • AUTH_SYS → yes (numeric uid matching is the “security” method)
  • Name Service Switch (NSS)
    • LDAP → no (Lightweight Directory Access Protocol)
    • SSS → no (System Security Services Daemon)
    • files → yes

But does it work?

  • mounts work.
  • I/O works.

Feels like the idmapper is never even being called.

Logging

  • Jack up verbosity outrageously causes no change in the output.
  • /var/log/messages
  • Therefore, ID mapping isn’t occurring at all.

Specimen

From the client

Jul 25 23:16:39 client rpc.idmapd[2423]: libnfsidmap: using domain: example.com
Jul 25 23:16:39 client rpc.idmapd[2423]: libnfsidmap: Realms list: 'EXAMPLE.COM'
Jul 25 23:16:39 client rpc.idmapd[2423]: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch
Jul 25 23:16:39 client rpc.idmapd[2424]: Expiration time is 600 seconds.
Jul 25 23:16:39 client rpc.idmapd[2424]: Opened /proc/net/rpc/nfs4.nametoid/channel
Jul 25 23:16:39 client rpc.idmapd[2424]: Opened /proc/net/rpc/nfs4.idtoname/channel
Jul 25 23:16:39 client rpc.idmapd[2424]: New client: 16
Jul 25 23:16:39 client rpc.idmapd[2424]: Opened /var/lib/nfs/rpc_pipefs//nfs/clnt16/idmap
Jul 25 23:16:39 client rpc.idmapd[2424]: New client: 1b
Jul 25 23:16:39 client rpc.idmapd[2424]: New client: 1d
Jul 25 23:16:39 client rpc.idmapd[2424]: Opened /var/lib/nfs/rpc_pipefs//nfs/clnt1d/idmap
Jul 25 23:16:39 client rpc.idmapd[2424]: New client: 22
Jul 25 23:16:39 client rpc.idmapd: rpc.idmapd: libnfsidmap: using domain: example.com
Jul 25 23:16:39 client rpc.idmapd: rpc.idmapd: libnfsidmap: Realms list: 'EXAMPLE.COM'
Jul 25 23:16:39 client rpc.idmapd: rpc.idmapd: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch
<snip/>
Jul 25 23:21:08 client rpc.idmapd[2424]: Stale client: 22
Jul 25 23:21:08 client rpc.idmapd[2424]: -> closed /var/lib/nfs/rpc_pipefs//nfs/clnt22/idmap
Jul 25 23:21:08 client rpc.idmapd[2424]: Stale client: 1d
Jul 25 23:21:08 client rpc.idmapd[2424]: -> closed /var/lib/nfs/rpc_pipefs//nfs/clnt1d/idmap
Jul 25 23:21:08 client rpc.idmapd[2424]: Stale client: 1b
Jul 25 23:21:08 client rpc.idmapd[2424]: -> closed /var/lib/nfs/rpc_pipefs//nfs/clnt1b/idmap
Jul 25 23:21:08 client rpc.idmapd[2424]: Stale client: 16
Jul 25 23:21:08 client rpc.idmapd[2424]: -> closed /var/lib/nfs/rpc_pipefs//nfs/clnt16/idmap

Configurations

client & server (2 machines)

  • NFSv4
  • Firewall (iptables, ip6tables)
    • client → yes (default ruleset)
    • server → no (none)
  • Fedora
    • kernel 3.11
    • kernel 4..0

client

  • wbaker → uid 2500
  • nsswitch → /etc/passwd
  • address → (IPv6) 2001:db8::1234
  • Fedora 21
    $ uname -r
    4.0.8-200.fc21.x86_64
    $ rpm -q -a | grep -Ee '(nfs-utils|kernel)-' | sort
    kernel-4.0.8-200.fc21.x86_64
    kernel-core-4.0.8-200.fc21.x86_64
    kernel-modules-4.0.8-200.fc21.x86_64
    nfs-utils-1.3.1-6.4.fc21.x86_64
  • $ sysctl kernel.keys.root_maxkeys
    kernel.keys.root_maxkeys = 1000000
    $ sysctl kernel.keys.maxkeys
    kernel.keys.maxkeys = 200

server

  • wbaker → uid 500
  • nsswitch → /etc/passwd
  • address → (IPv6) 2001:db8::9876
  • Fedora 18
    $ uname -r
    3.11.10-100.fc18.x86_64
    $ rpm -q -a | grep -Ee '(nfs-utils|kernel)-' | sort
    kernel-3.11.10-100.fc18.x86_64
    nfs-utils-1.2.7-6.fc18.x86_64
  • $ sysctl kernel.keys.root_maxkeys
    kernel.keys.root_maxkeys = 200
    $ sysctl kernel.keys.maxkeys
    kernel.keys.maxkeys = 200

Server

/etc/idmapd.conf

[General]
Verbosity = 10
Domain = example.com
#Local-Realms = 
[Mapping]
#Nobody-User = nobody
#Nobody-Group = nobody
[Translation]
#Method = nsswitch
#GSS-Methods = <alternate method list for translating GSS names>
[Static]
<snip/>

Client

/etc/idmapd.conf

[General]
Verbosity = 100
Domain = example.com
#Local-Realms = 
[Mapping]
#Nobody-User = nobody
#Nobody-Group = nobody
[Translation]
#Method = nsswitch
#GSS-Methods = <alternate method list for translating GSS names>
[Static]
<snip/>

/proc/mounts

client$ grep nfs /proc/mounts
server:/mnt/documents /areas/documents nfs4 rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=sys,clientaddr=2001:db8::1234,local_lock=none,addr=2001:db8::9876 0 0

More readable… (in order of appearance)

rw
relatime
vers=4.0
rsize=1048576
wsize=1048576
namlen=255
hard
proto=tcp6
port=0
timeo=600
retrans=2
sec=sys
clientaddr=2001:db8::1234
local_lock=none
addr=2001:db8::9876

Artifacts

Files

  • /proc
    • /proc/keys
    • /proc/key-users
  • /etc/modprobe.d
    • /etc/modprobe.d/nfs.conf (you create this)
      options nfs nfs4_disable_idmapping=1 (else 0 to enable)
  • /sys/module/nfs/parameters
    • /sys/module/nfs/parameters/nfs4_disable_idmapping
    • /sys/module/nfsd/parameters/nfs4_disable_idmapping
  • /etc/idmapd.conf
  • /etc/request-key.conf
  • /etc/request-key.conf.d/
    • /etc/request-key.conf.d/cifs.idmap.conf (CIFS)
    • /etc/request-key.conf.d/cifs.spnego.conf (CIFS)
    • /etc/request-key.conf.d/id_resolver.conf (NFSv4)
  • /lib/systemd/system
    • /lib/systemd/system/nfs-idmapd.service
      /lib/systemd/system/nfs-idmap.service is a symlink to nfs-idmapd.service
  • /run/sysconfig/nfs-utils

Operations

  • nfsidmap -c
  • request-key

Folklore

  • Changes in NFS portended by NFS v4 → NFS v4.1
  • Changes in the Linux kernel circa 3.2 → 3.3

Discussion

  • NFSv4 HOWTO; Some dude using the self-asserted identity token bryanquigley; In Ubuntu Documentation; 2014-06-26
    tl;dr → yet it references Fedora Core 2 for subsequent learning, reminds that in AUTH_SYS that authorization decisions are still done by uid & gid equality whereas reporting may or may not be mapped by idmapper (the statements are inconclusive).
  • 997164rpc.idmapd: nss_getpwnam: name ‘#’ does not map into domain; In Red Hat Bugzilla; 2013-08-14 → 2015-01-26.
  • 876705default maximum number of keys (200) too small for nfs4 uid-user mapping; In Red Hat Bugzilla; 2012-11-14 → 2015-05-22.
    tl;dr → discusses capacity of the kernel keyring, but follow the thread about NFSv4 idmapping enablement (disablement)

    • Comment 13hints that NFSv4 id mapping is (has always been) disabled
      • /sys/module/nfs/parameters/nfs4_disable_idmapping
        /sys/module/nfsd/parameters/nfs4_disable_idmapping
    • NFSv4, Name (string) mapping vs. raw UID, idmapd and Kernels >= 3.3; In linux-nfs@vger.kernel.org; 2012-08-23.
      tl;dr → <quote>Yes, newer Linux servers by default do return numeric ID’s (unless Kerberos is used).</quote> where “newer” is defined as >= 3.3.
  • 847084fsidmap failing to show id of some users when using LXDM greeter user list; In Red Hat Bugzilla; 2012-08-09 → 2012-11-15.
    tl;dr → inconclusive, closed as a duplicate of 876705 (a different effect)
  • NFSv4 Client side ID mapping does not work in Tumbleweed kernel 3.3.1-19-desktop; In Novell Bugzilla; 2012-04-12 → 2013-06-19.
    tl;dr → broken circa kernel-3.3, claimed fixed in 3.6
  • 966734nfs4+idmap does not map uids correctly when using AUTH_SYS; In Ubuntu nfs-utils Package, Bugs; 2012-03-28 → 2015-05-12.
    tl;dr → rambles along for three years finally, asserting in Comment 18 that id mapping does not work ever, at all; clearly not for authorization but also not even for the mere reporting case (e.g. the use of /bin/ls).
    Cites syslog message not shown in more recent venues:
    Server's syslog: rpc.idmapd[777]: Server : (user) id "2012" -> name "postie@localdomain"
    Client's syslog: rpc.idmapd[870]: Client 0: (user) name "postie@localdomain" -> id "2014"
  • [SOLVED]nfs idmap problems, nobody is owner of all files; some dude using the self-asserted identity token wmark; In Gentoo Discussion Forums; 2012-02-22.
    tl;dr → inconclusive, early days of NFSv4/NFSv4.1, years ago, a recipe for configuring idmapper (rpc.idmapd) and using the Static clause to override.
  • [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter; Trond Myklebust; In linux-nfs@vger.kernel.org; 2012-01-09.
    tl;dr → inconclusive; a discussion concerning whether “numeric sensing” should be returned to default-on status in nfs.nfs4_disable_idmapping, or an export flag, or a proposed idmap config setting ServerNumericMapping. Ends in the word <quote>maybe.</quote>
  • Problem with NFSv4 and idmapd; Some dude using the self-asserted identity token Ping-wine; In Ubuntu Forums; 2011-07-06.
    tl;dr → exhibits syslog messages showing id mapping actually occurring

    • Server
      Jul 5 16:13:00 server rpc.idmapd[824]: libnfsidmap: using domain: dom.ain
      Jul 5 16:13:00 server rpc.idmapd[824]: libnfsidmap: loaded plugin /usr/lib/libnfsidmap/nsswitch.so for method nsswitch
      Jul 5 16:13:00 server rpc.idmapd[827]: Expiration time is 600 seconds.
      Jul 5 16:13:00 server rpc.idmapd[827]: Opened /proc/net/rpc/nfs4.nametoid/channel
      Jul 5 16:13:00 server rpc.idmapd[827]: Opened /proc/net/rpc/nfs4.idtoname/channel
      Jul 5 16:13:25 server rpc.idmapd[827]: nfsdcb: authbuf=client.dom.ain authtype=user
      Jul 5 16:13:25 server rpc.idmapd[827]: nfs4_uid_to_name: calling nsswitch->uid_to_name
      Jul 5 16:13:25 server rpc.idmapd[827]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
      Jul 5 16:13:25 server rpc.idmapd[827]: nfs4_uid_to_name: final return value is 0
      Jul 5 16:13:25 server rpc.idmapd[827]: Server: (user) id "0" -> name "root@dom.ain"
      Jul 5 16:13:25 server rpc.idmapd[827]: nfsdcb: authbuf=client.dom.ain authtype=group
      Jul 5 16:13:25 server rpc.idmapd[827]: nfs4_gid_to_name: calling nsswitch->gid_to_name
      Jul 5 16:13:25 server rpc.idmapd[827]: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
      Jul 5 16:13:25 server rpc.idmapd[827]: nfs4_gid_to_name: final return value is 0
      Jul 5 16:13:25 server rpc.idmapd[827]: Server: (group) id "0" -> name "root@dom.ain"
    • Client
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_uid: calling nsswitch->name_to_uid
      Jul 5 16:17:34 client rpc.idmapd[770]: nss_getpwnam: name 'user1@dom.ain' domain 'dom.ain': resulting localname 'user1'
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_uid: final return value is 0
      Jul 5 16:17:34 client rpc.idmapd[770]: Client 0: (user) name "user1@dom.ain" -> id "1003"
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_gid: calling nsswitch->name_to_gid
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_gid: final return value is 0
      Jul 5 16:17:34 client rpc.idmapd[770]: Client 0: (group) name "user1@dom.ain" -> id "1003"
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_uid: calling nsswitch->name_to_uid
      Jul 5 16:17:34 client rpc.idmapd[770]: nss_getpwnam: name 'user2@dom.ain' domain 'dom.ain': resulting localname 'user2'
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_uid: final return value is 0
      Jul 5 16:17:34 client rpc.idmapd[770]: Client 0: (user) name "user2@dom.ain" -> id "1004"
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_gid: calling nsswitch->name_to_gid
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
      Jul 5 16:17:34 client rpc.idmapd[770]: nfs4_name_to_gid: final return value is 0
      Jul 5 16:17:34 client rpc.idmapd[770]: Client 0: (group) name "user2@dom.ain" -> id "1004"

References

 

SOLVED: sendmail hangs on a lock when /etc/mail/aliases.db is “unfresh”; rerun newaliases to clear

Bug 664161sendmail hangs on a lock when /etc/mail/aliases.db is “unfresh”; rerun newaliases to clear; In Red Hat Bugzilla; 2010-12-18 14

  • Reported against Fedora 14
  • Manifests in Fedora 16 as well
$ rpm -q sendmail
sendmail-8.14.5-11.fc16.i686

Concept

The sense is that there is a warning or error message that is being emitted, but it isn’t flushed.  The use of sendmail -v does not exhibit the message, but SIGINT (^C) during the waiting period seems to flush out something (not shown).

Remediation

Run newaliases.
Restart sendmail.

Prophylaxis

Run newaliases early and often.

SOLVED: Mail Delivery is Busted | sendmail OK, spamassassin fails with ‘bayes: expire_old_tokens: child processing timeout at /usr/bin/spamd line 1316.’

Complaint

Spam Assassin has gotten wedged. Whereas sendmail is operating just fine, all mail traffic is being rejected with 451 4.3.2 Please try again later.
Something about a timeout. Something about expiration of old bayes tokens. As it stands, mail transmission is busted and no amount of daemon restarting or rebooting will make it function.

Remediation

$ sudo systemctl stop spamassassin.service
$ sudo bash
# cd /var/lib/spamass-milter/.spamassassin
# mkdir j
# mv * j/.
mv: cannot move `j' to a subdirectory of itself, `j/./j'
# mv j/user_prefs .
# exit
$ sudo systemctl restart spamassassin.service

Context

$ rpm -q sendmail spamassassin spamass-milter milter-greylist
sendmail-8.14.5-11.fc16.i686
spamassassin-3.3.2-14.fc16.i686
spamass-milter-0.3.2-4.fc16.i686
milter-greylist-4.2.7-1600.fc16.i686
$ cat /etc/fedora-release
Fedora release 16 (Verne)

References

  • Setting up a cron job to force Bayes Expiry; In Apache SpamAssassin Documentation; 2009-09-20.
    tl;dr → this procedure was ineffectual but sparked the concept that removing the bayes learning data wholesale was an option.
  • sa-learn especially the sections Exipration, Expiration Logic, Expiration Pass Logic and Expiry-Related Configuration Settings; In Apache SpamAssassin Documentation; undated
    bayes_auto_expire
    is used to specify whether or not SpamAssassin ought to opportunistically attempt to expire the Bayes database. The default is 1 (yes).
    bayes_expiry_max_db_size
    specifies both the auto-expire token count point, as well as the resulting number of tokens after expiry as described above. The default value is 150,000, which is roughly equivalent to a 6Mb database file if you’re using DB_File.
    bayes_journal_max_size
    specifies how large the Bayes journal will grow before it is opportunistically synced. The default value is 102400 [records, bytes, seconds? maybe records].

Indications

Jul 19 09:04:54 example.com sendmail[14554]: t6JG4sL7014554: from=, size=641, class=0, nrcpts=1, msgid=, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
Jul 19 09:04:54 example.com spamd[12990]: spamd: connection from localhost [127.0.0.1] at port 33118
Jul 19 09:04:54 example.com spamd[12990]: spamd: setuid to sa-milt succeeded
Jul 19 09:04:54 example.com spamd[12990]: spamd: processing message  for sa-milt:497
Jul 19 09:05:01 example.com spamd[12990]: spamd: clean message (-99.4/5.0) for sa-milt:497 in 7.2 seconds, 992 bytes.
Jul 19 09:05:01 example.com spamd[12990]: spamd: result: . -99 - ALL_TRUSTED,BAKER_BLOCK_GEO_FUZZY16_ROW_BUT_MAYBE_US,BAKER_BLOCK_IP4,BAKER_KNOWN_DNS_WHITE,BAYES_00 scantime=7.2,size=992,user=sa-milt,uid=497,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=33118,mid=,bayes=0.000000,autolearn=unavailable
Jul 19 08:52:30 example.com sendmail[14060]: t6JFlTKh014060: Milter (spamassassin): timeout before data read, where=eom
Jul 19 08:52:30 example.com sendmail[14060]: t6JFlTKh014060: Milter (spamassassin): to error state
Jul 19 08:52:30 example.com sendmail[14060]: t6JFlTKh014060: Milter: data, reject=451 4.3.2 Please try again later
Jul 19 08:52:30 example.com spamd[12990]: bayes: expire_old_tokens: child processing timeout at /usr/bin/spamd line 1316.

Actualities

Prior to the remediation … witness the orphaned lock files.

$ sudo bash
# cd /var/lib/spamass-milter/.spamassassin
# ls -als
total 143912
-rw-------. 1 sa-milt sa-milt        33 Jul 19 09:21 bayes.lock
-rw-------. 1 sa-milt sa-milt       192 Dec  9  2014 bayes.lock.example.com.1213
-rw-------. 1 sa-milt sa-milt        96 May 20 06:05 bayes.lock.example.com.1328
-rw-------. 1 sa-milt sa-milt       288 Jul  7  2014 bayes.lock.example.com.1564
-rw-------. 1 sa-milt sa-milt        64 Nov 18  2014 bayes.lock.example.com.1688
-rw-------. 1 sa-milt sa-milt        33 Jan  4  2015 bayes.lock.example.com.17102
-rw-------. 1 sa-milt sa-milt        96 May 12 05:29 bayes.lock.example.com.1899
-rw-------. 1 sa-milt sa-milt       224 Oct 29  2014 bayes.lock.example.com.2051
-rw-------. 1 sa-milt sa-milt        33 Nov 18  2014 bayes.lock.example.com.20554
-rw-------. 1 sa-milt sa-milt       297 Nov 14  2014 bayes.lock.example.com.20805
-rw-------. 1 sa-milt sa-milt        66 Jul  8  2014 bayes.lock.example.com.23931
-rw-------. 1 sa-milt sa-milt        33 Apr 15  2014 bayes.lock.example.com.24013
-rw-------. 1 sa-milt sa-milt        99 Jul  8  2014 bayes.lock.example.com.24075
-rw-------. 1 sa-milt sa-milt        64 Feb 17 05:05 bayes.lock.example.com.2705
-rw-------. 1 sa-milt sa-milt       264 Dec 31  2014 bayes.lock.example.com.31499
-rw-------. 1 sa-milt sa-milt        96 Jan 17  2015 bayes.lock.example.com.7714
-rw-------. 1 sa-milt sa-milt       248 Jul  8 05:07 bayes.lock.example.com.980
-rw-------. 1 sa-milt sa-milt  20193280 Jul 19 09:21 bayes_seen
-rw-------. 1 sa-milt sa-milt 167899136 Jul 19 09:21 bayes_toks
-rw-r--r--. 1 sa-milt sa-milt      1869 Nov  5  2012 user_prefs
# less bayes_*
"bayes_seen" may be a binary file.  See it anyway? 
"bayes_toks" may be a binary file.  See it anyway?

After the intervention (when delivery occurs happily):

# sudo find /var/lib/spamass-milter/.spamassassin -name j -prune -o -print
/var/lib/spamass-milter/.spamassassin
/var/lib/spamass-milter/.spamassassin/bayes_seen
/var/lib/spamass-milter/.spamassassin/bayes_toks
/var/lib/spamass-milter/.spamassassin/user_prefs

Bringing up wirelessness (wlp6s0) on the Dell M3800 under Fedora 21

Solution

You need the packages

  • broadcom-wl
  • kmod-wl

Automatically

  • With the correct driver module installed, it “just works” on boot.

Manually

  • modprobe wl

Witness

$ ip addr show wlp6s0
5: wlp6s0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether c4:8e:8f:f4:ec:fd brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.64/24 brd 192.168.1.255 scope global dynamic wlp6s0
       valid_lft 3563sec preferred_lft 3563sec
    inet6 fe80::c68e:8fff:fef4:ecfd/64 scope link 
       valid_lft forever preferred_lft forever

Original State

  • Works under the factory-installed Ubunto 14.14
  • Not recognized under stock Fedora 21 (wlan0 does not even show up).

Previously

  • Bringing up Fedora 21 on the Dell M3800 with a 4K2K Display; herein; 2015-07-07.
    tl;dr → partial success in bringup

    • wireless networking → unsolved (solved here)
    • wireline networking → solved (pesky dongle)
    • HiDPI Display → solved (GNOME settings)
    • Bluetooth → partial, you need a blob, the blob survive suspend-resume; status.
    • Suspend/Resume → UNSOLVED remains not working (does not suspend, dangerously overheats, arbitrary hang of the GPU); this makes the machine substantially unuseable beyond the hobbyist/tinkerist use case. status
  • Dell M3800 Mobile Workstation, ships with Linux, herein; 2015-03-31.
    tl;dr → promotional images, references to the promotional history

Dell M3800, ships with LinuxDell Precision M3800 Mobile workstation, ships with Linux

Configured
  • Ubuntu, surely it will work with Fedora
  • 4K2K display (3180×2160)
  • 16GB RAM
  • 1TB mSATA
Standard
  • NVIDIA Quadro K1100M
  • 4th Generation Intel i7 (Haswell)
Issues
  • No RJ45 Ethernet; need a USB-to-Ethernet dongle. :-(

Factoids

  • Broadcom Corporation BCM4352 802.11ac Wireless Network Adapter
  • Fedora 21
  • Kernel 4.0.6 (upgraded from the stock install)

broadcom-wl

This package contains the license, README.txt and configuration files for the Broadcom 802.11 Linux STA Driver for WiFi, a Linux device driver for use with Broadcom\’s BCM4311-, BCM4312-, BCM4313-, BCM4321-, BCM4322-, BCM43142-, BCM43224-, BCM43225-, BCM43227-, BCM43228-, BCM4331-, BCM4360 and -BCM4352- based hardware.

Content of RPM:
/etc/akmods/akmod-wl/api
/etc/dracut.conf.d/20-wl.conf
/usr/lib/modprobe.d/broadcom-wl-blacklist.conf
/usr/share/doc/broadcom-wl
/usr/share/doc/broadcom-wl/LICENSE.txt
/usr/share/doc/broadcom-wl/README_6.30.223.248.txt
/usr/share/doc/broadcom-wl/fedora.readme

Folklore

Based on information, belief & hearsay, as seen written.

  • Broadcom is not “well-supported” in Linux prior to kernel 3.17.x
    Atheros & Intel are “well-supported”
  • Something about the 3.17 kernel not working with kernel 3.17

Experiences

References

  • brcm80211Broadcom brcmsmac(PCIe) and brcmfmac(SDIO/USB) drivers; In Linux Wireless, a wiki.
    tl;dr → does not seem to mention the Broadcom BCM4352
  • Broadcom 802.11 Drivers for Linux; Broadcom
    tl;dr → unhelpful.
  • 1027651Wireless driver for Broadcom BCM4352 802.11 Hybrid Wireless Controller 6.30.223.95; In Red Hat Bugzilla; 2013-11-07 → 2014-03-19.
    tl;dr → mentions brdcm80211 is not in Fedora because <quote ref=”commentariat“> <snip/>is only partially compiled and the majority is a binary blob. That is all the excuse one need to not push it upstream.</quote>  Broadcom gets a FAIL on Open Source (through 2014-03).
    Claimed in <quote ref=”brcm80211“>Completely open source host drivers, no binary object files. </quote>

Actualities

$ ifconfig -a
ifconfig: reminder, is interactive; using ip instead
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s20u3:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 9c:eb:e8:24:3a:98 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.158/24 brd 192.168.0.255 scope global dynamic enp0s20u3
       valid_lft 86101sec preferred_lft 301sec
    inet6 fdd3:34cd:f133:0:9eeb:e8ff:fe24:3a98/64 scope global noprefixroute dynamic 
       valid_lft 86396sec preferred_lft 86396sec
    inet6 fe80::9eeb:e8ff:fe24:3a98/64 scope link 
       valid_lft forever preferred_lft forever
3: virbr0:  mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 82:7d:3d:25:6b:f6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
$ rfkill list
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
1: nfc0: NFC
	Soft blocked: no
	Hard blocked: no
$ lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:04.0 Signal processing controller: Intel Corporation Device 0c03 (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d5)
00:1c.4 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #5 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation HM87 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
00:1f.6 Signal processing controller: Intel Corporation 8 Series Chipset Family Thermal Management Controller (rev 05)
02:00.0 3D controller: NVIDIA Corporation GK107GLM [Quadro K1100M] (rev a1)
06:00.0 Network controller: Broadcom Corporation BCM4352 802.11ac Wireless Network Adapter (rev 03)
07:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5249 PCI Express Card Reader (rev 01)
$ lsusb
Bus 004 Device 002: ID 8087:8000 Intel Corp. 
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:8008 Intel Corp. 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0a5c:216f Broadcom Corp. 
Bus 001 Device 003: ID 04f3:21f9 Elan Microelectronics Corp. 
Bus 001 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. 
Bus 001 Device 005: ID 0bda:573c Realtek Semiconductor Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ cat /etc/modprobe.d/openfwwf.conf 
options b43 nohwcrypt=1 qos=0
$ rpm -q -f /etc/modprobe.d/openfwwf.conf
b43-openfwwf-5.2-11.fc21.noarch
$ sudo yum install -y broadcom-wl
Loaded plugins: auto-update-debuginfo, langpacks
collected-by-http                                                                                   | 3.0 kB  00:00:00
rpmfusion-free-updates                                                                              | 2.7 kB  00:00:00
rpmfusion-nonfree-updates                                                                           | 2.7 kB  00:00:00
updates/21/x86_64/metalink                                                                          |  12 kB  00:00:00
updates                                                                                             | 4.9 kB  00:00:00
updates/21/x86_64/primary_db                                                                        | 8.4 MB  00:00:29
(1/4): rpmfusion-nonfree-updates/21/x86_64/primary_db                                               | 146 kB  00:00:01
(2/4): rpmfusion-free-updates/21/x86_64/primary_db                                                  | 355 kB  00:00:01
(3/4): updates/21/x86_64/updateinfo                                                                 | 1.3 MB  00:00:06
(4/4): updates/21/x86_64/pkgtags                                                                    | 1.6 MB  00:00:13
Resolving Dependencies
--> Running transaction check
---> Package broadcom-wl.noarch 0:6.30.223.248-3.fc21 will be installed
--> Processing Dependency: wl-kmod >= 6.30.223.248 for package: broadcom-wl-6.30.223.248-3.fc21.noarch
--> Running transaction check
---> Package kmod-wl.x86_64 0:6.30.223.248-8.fc21.5 will be installed
--> Processing Dependency: kmod-wl-4.0.7-200.fc21.x86_64 >= 6.30.223.248-8.fc21.5 for package: kmod-wl-6.30.223.248-8.fc21.5.x86_64
--> Running transaction check
---> Package kmod-wl-4.0.7-200.fc21.x86_64.x86_64 0:6.30.223.248-8.fc21.5 will be installed
--> Processing Dependency: kernel-uname-r = 4.0.7-200.fc21.x86_64 for package: kmod-wl-4.0.7-200.fc21.x86_64-6.30.223.248-8.fc21.5.x86_64
--> Running transaction check
---> Package kernel-core.x86_64 0:4.0.7-200.fc21 will be installed
--> Finished Dependency Resolution
Dependencies Resolved

===========================================================================================================================
Package Arch Version Repository Size
===========================================================================================================================
Installing:
broadcom-wl noarch 6.30.223.248-3.fc21 rpmfusion-nonfree-updates 24 k
Installing for dependencies:
kernel-core x86_64 4.0.7-200.fc21 updates 19 M
kmod-wl x86_64 6.30.223.248-8.fc21.5 rpmfusion-nonfree-updates 19 k
kmod-wl-4.0.7-200.fc21.x86_64 x86_64 6.30.223.248-8.fc21.5 rpmfusion-nonfree-updates 1.5 M

Transaction Summary
===========================================================================================================================
Install 1 Package (+3 Dependent packages)

Total download size: 21 M
Installed size: 49 M
Downloading packages:
(1/4): broadcom-wl-6.30.223.248-3.fc21.noarch.rpm | 24 kB 00:00:00
(2/4): kmod-wl-6.30.223.248-8.fc21.5.x86_64.rpm | 19 kB 00:00:01
kernel-core-4.0.7-200.fc21.x86 FAILED ] 190 kB/s | 802 kB 00:01:47 ETA
ftp://ftp.uci.edu/mirrors/fedora/linux/updates/21/x86_64/k/kernel-core-4.0.7-200.fc21.x86_64.rpm: [Errno 14] curl#7 - "Failed to connect to ftp.uci.edu port 21: Connection refused"
Trying other mirror.
(3/4): kmod-wl-4.0.7-200.fc21.x86_64-6.30.223.248-8.fc21.5.x86_64.rpm | 1.5 MB 00:00:05
(4/4): kernel-core-4.0.7-200.fc21.x86_64.rpm | 19 MB 00:01:07
---------------------------------------------------------------------------------------------------------------------------
Total 299 kB/s | 21 MB 00:01:10
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction (shutdown inhibited)
Installing : kernel-core-4.0.7-200.fc21.x86_64 1/4
Installing : broadcom-wl-6.30.223.248-3.fc21.noarch 2/4
Installing : kmod-wl-4.0.7-200.fc21.x86_64-6.30.223.248-8.fc21.5.x86_64 3/4
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_scan_done
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_disconnected
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol wiphy_new_nm
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_inform_bss_width_frame
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol wiphy_register
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_put_bss
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_roamed
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_inform_bss_width
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_gtk_rekey_notify
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_ibss_joined
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_michael_mic_failure
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_connect_result
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol wiphy_unregister
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_get_bss
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol __ieee80211_get_channel
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol ieee80211_channel_to_frequency
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_report_wowlan_wakeup
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol ieee80211_frequency_to_channel
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol wiphy_free
Installing : kmod-wl-6.30.223.248-8.fc21.5.x86_64 4/4
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_scan_done
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_disconnected
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol wiphy_new_nm
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_inform_bss_width_frame
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol wiphy_register
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_put_bss
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_roamed
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_inform_bss_width
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_gtk_rekey_notify
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_ibss_joined
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_michael_mic_failure
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_connect_result
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol wiphy_unregister
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_get_bss
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol __ieee80211_get_channel
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol ieee80211_channel_to_frequency
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol cfg80211_report_wowlan_wakeup
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol ieee80211_frequency_to_channel
depmod: WARNING: /lib/modules/4.0.7-200.fc21.x86_64/extra/wl/wl.ko needs unknown symbol wiphy_free
Verifying : kmod-wl-4.0.7-200.fc21.x86_64-6.30.223.248-8.fc21.5.x86_64 1/4
Verifying : kmod-wl-6.30.223.248-8.fc21.5.x86_64 2/4
Verifying : broadcom-wl-6.30.223.248-3.fc21.noarch 3/4
Verifying : kernel-core-4.0.7-200.fc21.x86_64 4/4

Installed:
broadcom-wl.noarch 0:6.30.223.248-3.fc21

Dependency Installed:
kernel-core.x86_64 0:4.0.7-200.fc21 kmod-wl.x86_64 0:6.30.223.248-8.fc21.5
kmod-wl-4.0.7-200.fc21.x86_64.x86_64 0:6.30.223.248-8.fc21.5

Complee!
$ uname -a
Linux sonsie.example.com 4.0.6-200.fc21.x86_64 #1 SMP Tue Jun 23 13:59:12 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Somewhat SOLVED: Bringing up Fedora 21 on the Dell M3800 with a 4K2K Display

Just Works … (almost)completely

  • Installation of Fedora via wireline ethernet (network install) is not possible
  • Installation of Fedora via wireless network not offered.
  • Installation of Fedora via (legacy BIOS boot) USB media … just works.
  • Wireless networking does not work under Fedora [NOT SOLVEDSOLVED]

Once Fedora (Fedora 21) is installed, the network works as it should.

Background

Wireless Network

Does not work.  No wireless networking capability is recognized by Fedora. It worked under the native Ubuntu from Dell.  TODO.

Wireline Network

There s no win or workaround here.  Dell does not provide a wireline NIC on the M3800.  The USB dongle is not supported in BIOS during the network install scenario.  You lose.  You must use a USB stick.

Some dude explored all the options in Dell laptops, including the M3800 to assess which of the BIOS and USB-to-Ethernet dongles would “work.”  Windows-centric (there is some sort of Windows7-vs-Windows8 issue going on for that culture).  The net of the issue is that while the in-ROM PXE will operate the USB-to-Ethernet dongles for long enough to bring over a kernel, once the kernel itself attempts to assert control over the devices from PXE, then the USB controller drops back into HCI mode only, the network-capable hardware “disappears” off the USB bus.  There is no workaround, it is a (legacy) BIOS thing; UEFI does not support network booting in this scenario at all.

References

  • That blog post.

HiDPI Display

The whole point of this machine was the 4K2K display.  Wiithout intervention, it render similarly to an HDMI display, that is comfortable to read at 15″; to get it to use the full native resolution, which can be uncomfortable to read at 15″ you will need some settings.

To avail yourself of the “High DPI” screen you will need to establish that in GNOME, else you’ll have what amounts to a HDMI-scale screen.  At runtime, within a GNOME session, declare:

gsettings set org.gnome.desktop.interface scaling-factor 1

This wasn’t necessary when using a 31″ display (on Fedora 19 & Fedora 20), but is absolutely necessary using a 15″ display (on Fedora 21).

Definitions

<quote> cite=”ref”>HiDPI (High Dots Per Inch) displays, also known by Apple’s “Retina Display” marketing name, are screens with a high resolution in a relatively small format. They are mostly found in Apple products or high-end “ultrabooks”, as well as in 4K (Ultra HD) or even 5K monitors.</quote>

<quote cite=”ref“>Hi-dpi support means that applications render at half the available screen resolution to avoid content that is defined in terms of pixels from becoming tiny. Effectively, this means treating 2×2 blocks as device pixels as application pixels, with the extra twist that data that is available in high resolution (e.g. svgs or fonts) can be rendered at the full resolution. </quote>

References

  • HiDPI; Some Dude; In Arch Linux Wiki; 2015-07-05.
    tl;dr → declares for GNOME as the first solution recipe.
  • Hi-DPI; MatthiasClasen‘; In GNOME Wiki; 2014-12-21
    tl;dr → discursive, not very helpful avoids any mention of gsettings or org.desktop.interface.scaling-factor, mentions gnome-tweak-tool but not what to do with it, discusses detailed application-specific workarounds (avoid these, GNOME works just fine with scaling-factor)
  • How to debug Xorg problems; In Fedora Documentation; 2015.
    tl;dr → this is not a “problem” in Xorg, rather it is a feature of HiDPI displays
    Useful

    • /var/log/Xorg.0.logno longer exists in Fedora; each release has a different way of recovering the logfile, perhaps the changes have stabilized
      • Fedora 22 → journalctl -b _COMM=gdm-x-session
      • Fedora 21 → journalctl -b _COMM=Xorg.bin
      • Fedora 20 → journalctl -b _COMM=Xorg
      • Fedora 19 (& prior) still used /var/log/Xorg.0.log

Folklore

  • Use scaling-factor 2 to get something approximating an HDMI (HD-type) resolution.
  • Use scaling-factor 1 to get the native resolution
  • Use scaling-factor 0 to get (what?)
  • Use gsettings reset to recover the default
  • Use gsettings get to recover the current setting.
  • Of course, gnome-settings-daemon must be running.

Discussions

SOLVED: HOWTO Bring up git-daemon on Fedora 16 (with SELinux)

Problem Statement

Establish a git repository, git.example.com with the attributes

  • Available (readonly) via git://git.example.com/name.git
  • Use git-daemon
  • A web interface via cgit.
  • Must be on Fedora 16.
  • Repositories to be stored in name.git

Separately, there is a known success recipe which uses NFS file services, which must uses git_system_use_nfs=on and thus necessarily turns off SELinux. The assignment here is to continue using SELinux.

Solution

semanage fcontext -a -f 'all files' -t git_system_content_t '/var/git(/.*)?'

Working Recipe

Where this configuration “works”

$ getsebool -a | grep git
git_session_bind_all_unreserved_ports --> off
git_system_enable_homedirs --> off
git_system_use_cifs --> off
git_system_use_nfs --> on

Unhelpful

Always drama here…

  • 1034412 - SELinux is preventing /usr/libexec/git-core/git-daemon from ‘search’ accesses…, 2013-11-25 → 2013-12-13.
    • Pertains to Fedora 20, not to Fedora 16
    • Declared fixed in selinux-policy-3.12.1-105.fc20 (Fedora 20)
    • Mentions ~/public_git
    • Mentions git_user_content_t
  • git within SELinux Policy Documentation
    Unhelpful
  • git_selinux(8), selinux-policy-doc_2.20110726-3_all, Ubuntu Manual Pages.
    Pertains to selinux-policy-2.2 (Ubuntu) and we are on selinux-policy-3.10 (Fedora 16)
    Discusses creating policy modules for new repository types.
    git_system_content_t
    Set files with git_system_content_t if you want the Git system daemon to read the file, and if you want the file to be modifiable and executable by all “Git shell” users.
    git_session_content_t
    Set files with git_session_content_t if you want the Git session and system daemon to read the file, and if you want the file to be modifiable and executable by all users. Note that “Git shell” users may not interact with this type.
  • Jean-Paul Saman; Gitolite, git-daemon and SELinux; In His Blog; 2011-12-23; separately filled.
    Doesn’t match lived experience on Fedora 16 → recipe does not work, but background information is educational.

Background

$ cat /etc/fedora-release
Fedora release 16 (Verne)
$ uname -a
Linux opened.local 3.6.6-1.fc16.i686.PAE #1 SMP Mon Nov 5 17:11:25 UTC 2012 i686 i686 i386 GNU/Linux
$ rpm -q git cgit selinux-policy
git-1.7.7.6-1.fc16.i686
cgit-0.9.1-2.fc16.i686
selinux-policy-3.10.0-96.fc16.noarch

git clone gives “fatal: I don’t handle protocol ‘​https’” and “fatal: I don’t handle protocol ‘git’”

Weird … via cut & paste somehow (a “software glitch” as they say on TV).

failsgit clone --bare https://git.fedorahosted.org/git/koji koji.git
succeedsgit clone --bare https://git.fedorahosted.org/git/koji koji.git

The lines show up the same in emacs and in gnome-terminal (on the command line), just as they do here.

Specimen

At sigul: An automated gpg signing system
What you see if you cut & paste the URL off the page is:

$ git clone --bare https://git.fedorahosted.org/git/sigul.git sigul.git
Cloning into 'sigul'...
fatal: I don't handle protocol '<U+200B>https'

What your character rendering system does with <U+200B> may or may not highlight the problem to you.

Sources

(summarizing the style sheets in play)

<sheet>
@media screen {
 a.ext-link .icon {
  background: url(../extlink.gif) left center no-repeat;
  padding-left: 15px;
 }
</sheet>

Exhibiting the HTML in play

<p>
The development code for <tt>sigul</tt> is available by:
git clone <a href="https://git.fedorahosted.org/git/sigul" class="ext-link"><span class="icon"></span>https://git.fedorahosted.org/git/sigul</a>
</p>

Forensics

$ cat -ve

https://git.fedorahosted.org/git/sigul

M-bM-^@M-^Khttps://git.fedorahosted.org/git/sigul$
^C
$ od -t x1

https://git.fedorahosted.org/git/sigul

0000000 e2 80 8b 68 74 74 70 73 3a 2f 2f 67 69 74 2e 66
0000020 65 64 6f 72 61 68 6f 73 74 65 64 2e 6f 72 67 2f
^C
$ od -t c

https://git.fedorahosted.org/git/sigul

0000000 342 200 213   h   t   t   p   s   :   /   /   g   i   t   .   f
0000020   e   d   o   r   a   h   o   s   t   e   d   .   o   r   g   /
0000040   g   i   t   /   s   i   g   u   l  \n
0000052

Explanation

What? Why?


Watch … carefully …

$ ./character-fail-git-clone
$ ./character-fail-git-clone
git clone --bare https://git.fedorahosted.org/git/koji koji.git
Cloning into bare repository 'koji.git'...
fatal: I don't handle protocol 'https'

git clone --bare https://git.fedorahosted.org/git/koji koji.git
Cloning into bare repository 'koji.git'...
remote: Counting objects: 8493, done.
remote: Compressing objects: 100% (4692/4692), done.
remote: Total 8493 (delta 6113), reused 5200 (delta 3787)
Receiving objects: 100% (8493/8493), 2.10 MiB | 197.00 KiB/s, done.
Resolving deltas: 100% (6113/6113), done.
$ bash -xv ./character-fail-git-clone
git clone --bare https://git.fedorahosted.org/git/koji koji.git
+ git clone --bare '\342\200\213https://git.fedorahosted.org/git/koji' koji.git
Cloning into bare repository 'koji.git'...
fatal: I don't handle protocol 'https'

git clone --bare https://git.fedorahosted.org/git/koji koji.git
+ git clone --bare https://git.fedorahosted.org/git/koji koji.git
Cloning into bare repository 'koji.git'...
remote: Counting objects: 8493, done.        
remote: Compressing objects: 100% (4692/4692), done.        
remote: Total 8493 (delta 6113), reused 5200 (delta 3787)        
Receiving objects: 100% (8493/8493), 2.10 MiB | 197.00 KiB/s, done.
Resolving deltas: 100% (6113/6113), done.
cat -ve character-fail-git-clone
#!/bin/sh$
$
set -xv$
git clone --bare M-bM-^@M-^Khttps://git.fedorahosted.org/git/koji koji.git$
$
git clone --bare https://git.fedorahosted.org/git/koji koji.git$
$

SOLVED: httpd gives [error] (EAI 2)Name or service not known: Could not resolve host name *s — ignoring!

Indications

$ httpd -t -d `: need a full path ; cd ./opened/httpd; pwd` -f conf/httpd.conf
[thu Jan 01 01:01:01 2015] [error] (EAI 2)Name or service not known: Could not resolve host name *s -- ignoring

Diagnosis

One of the VirtualHost stanzas mentions the hostname *s

Remediation

Fix that. What was intended was * (star)

Actualities

<VirtualHost *s:9999>
SSLEngine On
ServerName www.example.com
DocumentRoot /var/www/html
...etc...
</VirtualHost>

and, as-repaired

Index: com.example.conf
===================================================================
--- com.example.conf    (revision 1234)
+++ com.example.conf    (working copy)
@@ -53,7 +53,7 @@
...etc...
-<VirtualHost *s:9999>
+<VirtualHost *:9999>
SSLEngine Off
ServerName www.example.com
DocumentRoot /var/www/html
...etc...

SOLVED autofs fails to mount NFS v3 on Fedora 21 with ‘Failed to start NFS status monitor for NFSv2/3 locking..’

Indications

  • autofs partially works
  • mounts NFSv4 volumes
  • fails to mount NFSv3 volumes

Remediation

systemctl enable rpcbind.service
systemctl start rpcbind.service

Configuration

  • Fedora 21
  • autofs
  • NFS client only (no NFS serving is to be provided)
  • A mixture of NFS servers
    • NFS v4 served from Fedora 18
    • NFS v3 served from ReadyNAS, where NFS v4 is not possible.
# rpm -q nfs-utils autofs
nfs-utils-1.3.1-6.3.fc21.i686
autofs-5.1.0-10.fc21.i686

Diagnostics

Jun 20 08:05:49 pert rpc.statd[471]: Version 1.3.1 starting
Jun 20 08:05:49 pert rpc.statd[471]: Flags: TI-RPC
Jun 20 08:05:49 pert rpc.statd[471]: Opening /var/run/rpc.statd.pid failed: Permission denied
Jun 20 08:05:49 pert systemd: rpc-statd.service: control process exited, code=exited status=1
Jun 20 08:05:49 pert systemd: Failed to start NFS status monitor for NFSv2/3 locking..
Jun 20 08:05:49 pert systemd: Unit rpc-statd.service entered failed state.
Jun 20 08:05:49 pert systemd: rpc-statd.service failed.
Jun 20 08:05:49 pert rpc.statd[473]: Version 1.3.1 starting
Jun 20 08:05:49 pert rpc.statd[473]: Flags: TI-RPC
Jun 20 08:05:49 pert kernel: [42669.994356] svc: failed to register lockdv1 RPC service (errno 97).
Jun 20 08:05:49 pert kernel: svc: failed to register lockdv1 RPC service (errno 97).

Followup

# ls -ld /var/run
lrwxrwxrwx. 1 root root 6 Jun 9 04:48 /var/run -> ../run
# ls -lad /run/rpc*
-r--r--r--. 1 root root 0 Jun 20 08:04 /run/rpcbind.lock
srw-rw-rw-. 1 root root 0 Jun 20 08:04 /run/rpcbind.sock
-rw-r--r--. 1 rpcuser rpcuser 4 Jun 20 08:05 /run/rpc.statd.pid
# ls -ladZ /run/rpc*
-r--r--r--. root root system_u:object_r:rpcbind_var_run_t:s0 /run/rpcbind.lock
srw-rw-rw-. root root system_u:object_r:rpcbind_var_run_t:s0 /run/rpcbind.sock
-rw-r--r--. rpcuser rpcuser unconfined_u:object_r:var_run_t:s0 /run/rpc.statd.pid

References

  • [SOLVED] AutoFS NFS doesn’t mount on startup, failed to create rpc, 2015-02-15
    tl;dr → Not really a solution so much as a reminder that rpcbind.service needs to be started to run an NFS client in NFS v2 & NFS v3; does not explain the failure of rpc-statd.
  • NFS no longer mounts: rpc-statd fails to start; Some dude using the self-asserted identity token Carpetsmoker; In Unix & Linux Stack Exchange; 2015-02-11.
    tl;dr → mentions rpcbind, rpc-statd and exhibits the messages from /var/log/messages
  • 1175005Cannot mount NFS v3 partition until after reboot; In Red Hat Bugzilla; 2014-12-16 → 2015-05-15.
    tl;dr → mentions rpcbind, rpc-statd, against nfs-utils-1.3.0 (here nfs-utils-1.3.1); provides remediation but no solution.

Actualities

# mkdir /tmp/tt
# mount -v -o vers=3 server.example.com:/vol/fedora /tmp/tt
mount.nfs: timeout set for Sat Jun 20 08:03:13 2015
Job for rpc-statd.service failed. See "systemctl status rpc-statd.service" and "journalctl -xe" for details.
^C
# systemctl status rpc-statd.service
● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
   Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; static)
   Active: failed (Result: exit-code) since Sat 2015-06-20 08:01:13 PDT; 20s ago
  Process: 378 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=1/FAILURE)

Jun 20 08:01:13 server.example.com rpc.statd[379]: Version 1.3.1 starting
Jun 20 08:01:13 server.example.com rpc.statd[379]: Flags: TI-RPC
Jun 20 08:01:13 server.example.com systemd[1]: rpc-statd.service: control process exited, code=exited status=1
Jun 20 08:01:13 server.example.com systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking..
Jun 20 08:01:13 server.example.com systemd[1]: Unit rpc-statd.service entered failed state.
Jun 20 08:01:13 server.example.com systemd[1]: rpc-statd.service failed.
# systemctl status rpcbind.service
● rpcbind.service - RPC bind service
   Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; static)
   Active: inactive (dead)
# systemctl enable rpcbind.service
Created symlink from /etc/systemd/system/sockets.target.wants/rpcbind.socket to /usr/lib/systemd/system/rpcbind.socket.
# systemctl start rpcbind.service
# mount -o vers=3 -v server.example.com:/vol/fedora /tmp/tt
mount.nfs: timeout set for Sat Jun 20 08:07:49 2015
Job for rpc-statd.service failed. See "systemctl status rpc-statd.service" and "journalctl -xe" for details.
mount.nfs: trying text-based options 'vers=3,addr=192.168.131.99'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.131.99 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.131.99 prog 100005 vers 3 prot UDP port 44102
# ls /tmp/tt
...output...
# systemctl status rpc-statd.service
● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
   Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; static)
   Active: failed (Result: exit-code) since Sat 2015-06-20 08:05:49 PDT; 19min ago
  Process: 470 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=1/FAILURE)

Jun 20 08:05:49 server.example.com rpc.statd[471]: Version 1.3.1 starting
Jun 20 08:05:49 server.example.com systemd[1]: rpc-statd.service: control process exited, code=exited status=1
Jun 20 08:05:49 server.example.com systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking..
Jun 20 08:05:49 server.example.com systemd[1]: Unit rpc-statd.service entered failed state.
Jun 20 08:05:49 server.example.com systemd[1]: rpc-statd.service failed.
# systemctl enable rpc-statd.service
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
# systemctl is-enabled rpcbind.service
static
# systemctl is-active rpcbind.service
active
# systemctl status rpcbind.service
● rpcbind.service - RPC bind service
   Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; static)
   Active: active (running) since Sat 2015-06-20 08:04:47 PDT; 30min ago
 Main PID: 454 (rpcbind)
   CGroup: /system.slice/rpcbind.service
           └─454 /sbin/rpcbind -w
#

NFS no longer mounts: rpc-statd fails to start