Misc. Linux Sysadmin tips

Got around to updating the home office machines, and thought it would be a good idea to keep some recurring tips handy:



Disabling SSH login for root user

1.  Edit /etc/ssh/sshd_config
2. Set PermitRootLogin to no (Remove # if present)
3. Add AllowUsers  
4. Save, then restart sshd: 
   $ service sshd restart

Setup Passwordless SSH:

1. Create SSH keypair with options, such as:
   $ ssh-keygen -b 5120
2. chmod created keypair: 
   $ chmod 600
3. SCP the public key to target machine.
4. On target machine:
   $ mkdir ~/.ssh$ chmod 700 ~/.ssh
5. If ~/.ssh/authorized_keys doesn't exist:
    move the public key from home folder to ~/.ssh/authorized_keys then
   $ chmod 600 ~/.ssh/authorized_keys
6. If it does exist, then append the public key to the authorized_keys: 
   $ cat >> ~/.ssh/authorized_keys, then delete the public key.
7. Test by SSHing to the target machine

Editing Hostnames

1. Edit /etc/sysconfig/network.  modify HOSTNAME= to FQDN
2. Edit /etc/hosts.  Add IP address with FQDN and shortname
3. Restart network services:
   $ /etc/init.d/network restart

com.apple.preference.displays.MirrorDisplays): Service only ran for 0 seconds. Grrrrrr.

I've had my Mac Pro 6,1 for a few months and noticed that the display crashes every few weeks, where the symptoms range from 1) screen is "frozen as-is", 2) while mouse cursor can move 3) Cannot click on anything on the screen. 4) System clock on screen is stuck at the time the displays froze, and 5) System is still responsive through SSH.

While there was some discussion on various boards about the issue being due to the AMD FirePro D500 and D700 cards, I have a pair of D300s in this unit, which aren't supposed to be impacted by the known Apple Issue.


This occurred again recently and after getting some time to dig into things further, I looked into /var/log/system.log file to see what was the most recent entries prior to the latest freeze episode.

Found the following:

Output snippet from /var/log/system.log
Apr  4 11:01:18 macpro com.apple.xpc.launchd[1] (com.apple.preference.displays.MirrorDisplays): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
Apr  4 11:01:28 macpro com.apple.xpc.launchd[1] (com.apple.preference.displays.MirrorDisplays): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
Apr  4 11:01:38 macpro com.apple.xpc.launchd[1] (com.apple.preference.displays.MirrorDisplays): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
Apr  4 11:01:58 macpro com.apple.xpc.launchd[1] (com.apple.preference.displays.MirrorDisplays): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
Apr  4 11:02:28 macpro com.apple.xpc.launchd[1] (com.apple.preference.displays.MirrorDisplays): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.


In digging around the web, found the above link on Stackexchange that talks about this issue being related to a particular issue with out an Apple plugin is behaving badly, and lists instructions on how to temporarily disable it:

Here's the overall steps taken:
Sourced from Stackechange article:
https://apple.stackexchange.com/questions/304745/mirrordisplays-error-every-30-seconds-in-system-log

1. Disable System Integrity Protection so you can edit the .plist file. Do this by rebooting into the recovery partition with cmd-R, open Terminal from the Utilities menu, and type:
   $ csrutil disable
2. Reboot, then edit the .plist file with this command:
   $ sudo vi /System/Library/LaunchAgents/com.apple.preference.displays.MirrorDisplays.plist
3. Comment out the line that causes the MirrorDisplays tool to load. Change this line:
      
4. To this:
   
5. Then, reboot and re-enable System Integrity Protection using the recovery partition as described above and type:
   $ csrutil enable
6. Reboot 

After implementing the changes, it appears that this has stopped the occurrence:

$ grep "MirrorDisplays): Service only ran" system.log | cut -d ':' -f1 | uniq -c

 164 Apr  4 11

 172 Apr  4 12

  47 Apr  4 13

   3 Apr  4 14

The above command is grepping the system.log for the event occurrence, then parsing based on the first colon ':' which filters out everything of the error past the Day and Hour. So the above output shows that at 11am it occurred 164 times, 12pm occurred 172 times, 1pm 47 and so on...

It's now almost 4pm and no occurrences since disabling!  Keeping fingers crossed that this will fix the freezing scenario, otherwise will continue trudging through the system.log file on the next freeze.

Quickly update user password in an automated fashion

 Helpful when updating a user password in a script for small test clusters:

$  ssh remoteserver 'useradd newuser;  $PASSWD_COMMAND'

where $PASSWD_COMMAND  is one of the following:

    echo -e "newpassword\newpassword" | passwd newuser

    echo "newuser:newpassword" | chpasswd

    echo "newpassword" | passwd --stdin newuser

Installing a public key on a linux box

1) Prep the linux system for remote access:

mkdir $HOME/.ssh
chmod -R og= $HOME/.ssh

Note: file must be mode -rw-------

2) Run puttygen.exe on the client to generate a public/private key-pair.

3) Save the private key locally on the client
4) Copy the key directly from the output window of puttygen
5) Paste into the file $HOME/.ssh/authorized_keys as a single line.
6) Under putty, locate the SSH -> Auth -> ensure to select the proper private key file for authentication