Linux

Bash script: recursive diff between remote hosts

 

This script will generate a recursive, unified diff between the same path on two remote servers. You set the CONNECT1 and CONNECT2 variables as necessary to point to your hosts/paths. Of course, the users you connect as must have read access to the files/directories you’re accessing.

#!/bin/bash

# USAGE: ./sshdiff DIRECTORY
#
# E.g. ./sshdiff static/css
# Generates a recursive diff between /var/www/css/static/css
# on two separate servers.

TEMP1=~/.tmp_site1
TEMP2=~/.tmp_site2

CONNECT1="user1@hostname1:/var/www/$1"
PORT1=22
CONNECT2="user2@hostname2:/var/www/$1"
PORT2=22

mkdir "$TEMP1"
mkdir "$TEMP2"
scp -rq -P "$PORT1" "$CONNECT1" "$TEMP1"
scp -rq -P "$PORT2" "$CONNECT2" "$TEMP2"
echo -e "\n\n\n\n\n"
clear
diff -urb "$TEMP1" "$TEMP2"
rm -r "$TEMP1"
rm -r "$TEMP2"

Bash: unbom (to remove UTF-8 BOMs)

 

Tests for and removes UTF8 BOMs.

#!/bin/bash
for F in $1
do
  if [[ -f $F && `head -c 3 $F` == $'\xef\xbb\xbf' ]]; then
      # file exists and has UTF-8 BOM
      mv $F $F.bak
      tail -c +4 $F.bak > $F
      echo "removed BOM from $F"
  fi
done

USAGE: ./unbom *.txt

The magic is tail -c +4 which strips the first 3 bytes.

Could this be an OpenSSH bug?

 

Last week I tried to SSH into my webhost account (on Site5) from work and—forgetting my password—it locked me out after several failed attempts. SSHd would just close the connection without asking my password.

work:~$ ssh user@example.com
Connection closed by xx.xx.xx.xx

I could log in from any other location, so I figured it was an IP ban and after a few days and a support ticket, I’d be in, but things got strange.

  1. The Site5 techs could not find any evidence of a block on my account. They were pretty responsive.
  2. It couldn’t be an IP block because I could log in from a virtual machine which used my workstation IP as gateway.
  3. When connected to VPN (different public IP) it still refused me.
  4. It couldn’t be a port 22 block because I could attempt a login to a different account on the same host and it would give me a password prompt.
  5. Could it be Snow Leopard? I could log in from another workstation running it.
  6. My machine? I could log in to several other hosts, including another account on a different Site5 host.

On the server I had an ~/.ssh/authorized_keys file with an old public key—the file hadn’t been touched for 2 years. I deleted it and—voila—SSHd would again ask for my password and log me in fine.

Why would the presence of authorized_keys cause SSHd to refuse to give a password prompt to one particular client’s connection to one particular account? OSX did give me a default RSA keypair, but even if the public key had been forwarded, SSHd should revert to password auth if it doesn’t find it in authorized_keys.

Configuring Sendmail for UF’s SMTP

 

Our Ubuntu web host, hosted with OSG, was not able to send mail (using PHP mail) outside of UF. An OSG tech said our From: header should be a valid address at UF (check) and that the logs at smtp.ufl.edu showed those messages never made it there.

The solution was to configure sendmail to use smtp.ufl.edu as the “smart” relay host (as it’s described in the config file):

$ sudo nano /etc/mail/sendmail.cf

Ctrl+w and search for smart. On the line below, add smtp.ufl.edu directly after DS with no space. The result should be:

# "Smart" relay host (may be null)
DSsmtp.ufl.edu

Ctrl-x and save the buffer.

Restart sendmail: $ sudo /etc/init.d/sendmail restart

As soon as I did this, the queued messages were sent out. I still don’t know why messages to ufl.edu succeeded while others sat in the queue.