Remote X11 application windows

When you are running an application on your local Mac from a remote SSH tunnel (via ssh -X), and that application needs to spawn windows programmatically, your local XQuartz server will not be able to draw the windows unless you set “Allow connections from network clients.”

screen-shot-2016-09-20-at-3-33-28-pm

We ran into this when running MatLab R2013 (or so) via an ssh tunnel from a remote RHEL6 compute server: the MATLAB script spawns windows that are java figures, and the local XQuartz server by default wouldn’t draw them — although oddly, they did spawn. With this switch set, it works, as shown:

screen-shot-2016-09-20-at-3-05-21-pm

Connecting an Ubuntu 16.04 client to an old-school NIS server

This is a legacy process, and should be replaced with a different process, using LDAP or something, in new installations. However, if you are working in a legacy environment, this should do the trick for relatively sane installations of NIS and new Ubuntu installations.

The NIS domainname is nisDomain. Please note that in the context of NIS databases, “domainname” is an arbitrary string (you just pick one) and has nothing to do with your canonical domain name in DNS. [in other words, replace nisDomain with your local NIS domain].

Server Configuration

Remember, please, to copy the database files before you edit them so that if you bork up royally, you can just go back easily. Use git, use cp, who cares, just make sure you have a known sane version to go back to quickly.

In order to add the client to the NIS database you, need to log into nisServer and edit the following files:

  • /etc/yp/ethers
  • /etc/yp/netgroup
  • /etc/yp/hosts

In ethers, you need to add the MAC (Ethernet) address. Get this information from the client machine by running ifconfig.
In netgroup, you need to add the client machine’s name.
In hosts, you need to add the IPv4 address and its name. Note that the IP address is assigned automatically via DHCP, and they are fairly static, but could change at any time.

Once that is done you need to:

cd /var/yp
sudo make

in order to rebuild the NIS database.
You shouldn’t need to do a service nis restart. You shouldn’t need to do a service ypbind restart.

Client Configuration

If you’re going to do this to more than one machine, configure it then clone it. Get it right once and use copies somehow, with whatever technology you usually use.

This article assumes that client machines should run an up-to-date installation of Ubuntu 16.04 LTS (Xenial Xerus). Please consider unattended-upgrades. Also, conventional wisdom states that you should have at least one local user on the machine.

Add nisServer to /etc/hosts, just for sanity:
File: /etc/hosts

127.0.0.1 localhost
192.168.1.X clientName
192.168.1.Y nisServer

Install the programs the client machine needs:
sudo apt install nis rpcbind nfs-common.
Upon installation you will be asked the NIS domainname, here nisDomain.
Add nisServers’s IP to /etc/yp.conf:
File: /etc/yp.conf

ypserver 192.168.1.Y

Explicitly set rpcbind as allowed over network:
File: /etc/hosts.allow

rpcbind:       127.0.0.1
rpcbind:       192.168.1.Y

Tell the client that NIS databases are available, and to query them first for the following categories by editing nsswitch. Note that there order of placement here matters; we have had anomalous permissions behavior if files precedes nis in some cases.
File: /etc/nsswitch.conf

passwd:         nis files
group:          nis files
shadow:         nis files
hosts:          nis files mdns4_minimal [NOTFOUND=return] dns
networks:       nis files
protocols:      db files nis
services:       db files nis
ethers:         db files nis
rpc:            db files nis
netgroup:       nis
publickey:      nis
automount:      nis
aliases:        nis

Ensure portmap starts on boot by adding service portmap start to /etc/rc.local:
File: /etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
service portmap start
exit 0

You need to run update-rc.d nis defaults to install nis services at boot time, however, note that the default script links the boot script as S01nis in /etc/rc5.d, so if you find that nis is failing after boot, defaults may not be sufficient and you can try again with a higher S number.

You could put your NFS shares in /etc/fstab. Or you could sudo apt install autofs
Autofs is the file system service that mounts the user’s home directory via NFS when the directory is needed, including at login. In order to configure it, you need to edit the following files:
File: /etc/auto.master

# This is a 'master' automounter map and it has the following format:
# mount-point [map-type[,format]:]map [options]
# For details of the format look at auto.master(5).
#
/misc   /etc/auto.misc
/home   /etc/auto.home
#
# NOTE: mounts done from a hosts map will be mounted with the
#       "nosuid" and "nodev" options unless the "suid" and "dev"
#       options are explicitly given.
#
#/net   -hosts
/net   yp     auto.net
#
# Include /etc/auto.master.d/*.autofs
# The included files must conform to the format of this file.
#
+dir:/etc/auto.master.d
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master

File: /etc/auto.home

# This is the trad way
*     nisServer:/home/&
#
# This is a way to do it by pulling a file from your nis directory on server
+auto.home

Note that +auto.home is a pointer reference to the /etc/yp/auto.home (or something similar) file on your nisServer.

Lastly, we have to configure lightdm, Ubuntu’s graphical login client. First, you have to enable manual logins via username. Second, there’s an is apparently an issue with some default sessions for some users, for some reason; at times, if the default session isn’t explicitly set, it borks. Anyway, it’s an easy fix. Create a local configuration by creating a conf file in the appropriate directory. Call it nis.conf or so. Basically lightdm will load *.conf in this dir when it runs, so you can call it anything. (This is debian convention.) This file has no man page, but googling around and trying variants helped. There’s a sample of the file (with syntax) at /usr/share/doc/lightdm/lightdm.conf.gz. Anyway, create this:
File: /etc/lightdm/lightdm.conf.d/nis.conf

[SeatDefaults]
greeter-show-manual-login=true
user-session=true

At this point, the client’s configuration is done. The client knows the server is there, and the server knows the client exists, so you should be able to log in with your nisServer credentials.

You need to sudo reboot to restart the client machine, ensure it brings the services up properly on every reboot, and log in to test it, preferably with more than one user.

The dreaded persistent gatekeeper dialog

Ok, so there’s a quirk in Mac OS X (el cap, at least) that if you install a mozilla product (or, probably, anything else) from the internet as one administrator, but don’t open them up and clear the Gatekeeper dialogs, then log out and log in as another user, the standard dialog noting that they are internet applications will persist. In other words, every single time the user who did not install the application opens it up, they’ll get a dialog box saying “This application is from the internet, are you sure…” yada yada yada. It’s annoying for them.

The solution is to log in as the original user, and launch the application, to clear the dialogs. The xattr trick doesn’t work here, for reasons unbeknownst to me. But in case you’re searching the web and it comes up, I hope this helps.

You could also try installing as the current user, if the permissions are sufficient.

Migrations

So, our infrastructure and communications teams just took us through a migration of our email system.

They did a fine job, but there were some bumps in the road. Most of the time, when you migrate email servers, it’s not too big of a deal; you’re in control of the machines, and you’re going to have fallovers and failsafes, etc.

However, note that from a user’s perspective, changing MX records and the intricacies of the DNS system are deep fu. So just try to make those changes on Sunday at 1 a.m. Trust me, it’s best that this is happening while everyone is sleeping, because the fewer conversations you have to have about DNS propagation & replication, the happier you will be.

There are other lessons that we learned, but that is the most important one.