Join AD domain after installing sssd without reboot

The problem

In my team’s experience, we have a known issue where we had to reboot after installing the domain-joining packages (sssd and realmd primarily) before we could actually join the domain.

If, you install the rpms and then without a reboot try to join the domain with realm, you get a failure.

# /usr/sbin/realm join --computer-ou="OU=Linux,OU=Resources" --user="linuxdomainjoin" "ad.example.com" timeout=30
realm: Couldn't connect to realm service: Error calling StartServiceByName for org.freedesktop.realmd: Timeout was reached

You can examine the journalctl output for a little more detail.

Jan 14 09:15:44 host73.ad.example.com realmd[75184]: couldn't claim service name on DBus bus: org.freedesktop.realmd
Jan 14 09:15:44 host73.ad.example.com realmd[75184]: couldn't claim service name on DBus bus: org.freedesktop.realmd
Jan 14 09:16:09 host73.ad.example.com dbus[3222]: [system] Failed to activate service 'org.freedesktop.realmd': timed out

Jan 14 09:19:13 host73.ad.example.com realmd[75942]: Loaded settings from: /usr/lib64/realmd/realmd-defaults.conf /usr/lib64/realmd/realmd-distro.conf
Jan 14 09:19:13 host73.ad.example.com realmd[75942]: holding daemon: startup
Jan 14 09:19:13 host73.ad.example.com realmd[75942]: starting service
Jan 14 09:19:13 host73.ad.example.com realmd[75942]: connected to bus
Jan 14 09:19:13 host73.ad.example.com realmd[75942]: released daemon: startup
Jan 14 09:19:13 host73.ad.example.com realmd[75942]: couldn't claim service name on DBus bus: org.freedesktop.realmd
Jan 14 09:19:13 host73.ad.example.com realmd[75942]: couldn't claim service name on DBus bus: org.freedesktop.realmd
Jan 14 09:20:01 host73.ad.example.com CROND[76060]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 14 09:20:43 host73.ad.example.com systemd[1]: realmd.service start operation timed out. Terminating.
Jan 14 09:20:43 host73.ad.example.com realmd[75942]: stopping service
Jan 14 09:20:43 host73.ad.example.com systemd[1]: Failed to start Realm and Domain Configuration.
Jan 14 09:20:43 host73.ad.example.com systemd[1]: Unit realmd.service entered failed state.
Jan 14 09:20:43 host73.ad.example.com systemd[1]: realmd.service failed.

The solution

Just restart dbus!

sudo systemctl restart dbus

WARNING! Because I haven’t done a lot of reading on the dbus topic, I cannot say that this is a safe procedure if you have existing workloads. My environment was a new build, so possibly blipping services was not a problem there.

Boot systems into different targets manually

Boot system into different targets manually

You need to modify the boot command. On the grub2 screen where it shows the boot options, press e to edit.
On the line that starts with linux16, append one of these possible values:

systemd.unit=emergency.target
systemd.unit=rescue.target
systemd.unit=multi-user.target
systemd.unit=graphical.target

With one of those items added to the kernel instruction, press CTRL+X to boot the kernel.

Reference

Weblinks

  1. https://www.youtube.com/watch?v=LgAI_n7NueY

Ssh into NATted VM via AutoSSH

Overview

Suppose you have a virtual machine running on a natted network connection. It can get out just fine to the Internet.
Now, with the network address translation (NAT), you can’t send traffic in to that network. So you can’t just ssh username@vm.example.com and get in. You are going to need something a little fancier to accomplish that. This document explains how to do that.

Sample environment

For this document, these example values will be used. The vm is centos.vm.example.com and the system on the main network is desktop.example.com. The desktop will have port 5000 be forwarded to the vm’s port 22, which is the standard ssh port.

Set up autossh

You need ssh connectivity between the vm and the physical host. Make sure you have an automatic log in from the vm to the physical host. A good way to do that is by having an ssh key. If you need to generate one on the vm and copy it to the physical machine, use these commands.
# on vm
ssh-keygen # follow the prompts

The next step is to copy it to the physical machine.
# still on vm
ssh-copy-id username@desktop.example.com

Check that you can log in automatically with
ssh username@desktop.example.com
Once that is done, install autossh and make a systemd service file and enable and start it.
yum -y install autossh
tf=/usr/lib/systemd/system/autossh-ssh.service
touch "${tf}"; chmod 0644 "${tf}"
cat <<EOF > "${tf}"
[Unit]
Description=AutoSSH tunnel service for ssh
After=network.target
[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -N -R 5000:localhost:22 username@desktop.example.com -p 22
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable autossh-ssh.service
systemctl start autossh-ssh.service

Using the reverse tunnel

To connect to centos.vm.example.com, you just need to do this:
ssh centosusername@localhost -p 5000

Bonus: nickname the connection and copy ssh key

What I did was set up my ~/.ssh/config file with the following snippet, so I can just use the nickname “centosvm.”

# in ~/.ssh/config, mode 0600
Host centosvm centosvm.vm.example.com
 User centosuser
 Hostname localhost
 Port 5000

I then copied my ssh id to that, so I could connect without a password.
ssh-copy-id centosvm

References

  1. https://www.everythingcli.org/ssh-tunnelling-for-fun-and-profit-autossh/
  2. http://www.harding.motd.ca/autossh/index.html
  3. http://surniaulula.com/2012/12/10/autossh-startup-script-for-multiple-tunnels/