chr.istoph, der Blog

Da es mir nicht möglich war, mit den in Debian Wheezy oder Ubuntu Trusty enthaltenen gitolite Paketen den gitserver so anzupassen, dass man hooks ausführen kann, habe ich die Methode gewählt wie sie auf der Gitolite Webseite beschreiben ist.

Client:
Zunächst benötigt man einen Key für den Administrator.
ssh-keygen -b 4096
scp .ssh/id_rsa.pub server:/tmp/chr.pub

Server:
Dann beginnt man auf dem Server die eigentliche Installation.
apt-get install git
adduser git --disabled-password
su - git
cd /home/git
mkdir bin
git clone git://github.com/sitaramc/gitolite
gitolite/install -ln ~/bin
gitolite setup -pk /tmp/chr.pub

Dann müssen noch zwei Konfigurationseinstellungen vorgenommen werden.
vim .gitolite.rc
GIT_CONFIG_KEYS => '.*',
LOCAL_CODE => "$ENV{HOME}/.gitolite/local-code/",

Client:
Die restliche Konfiguration kann dann vom Administrator Konto aus erledigt werden.
apt-get install git
git clone git@server:gitolite-admin
cd gitolite-admin
mkdir -p /local-code/hooks/common/hooks.d/

cat > local-code/hooks/common/hooks.d/runhook.sh <<\EOF
#!/bin/bash

echo "TEST" > /tmp/runhook.log
EOF
chmod -v +x local-code/hooks/common/hooks.d/runhook.sh

cat > local-code/hooks/common/post-receive <<\EOF
#!/bin/bash
run_hook () {
  echo -en "\e[1;33m$4..\e[00m "
  echo $1 $2 $3 | $GIT_DIR/hooks/hooks.d/$4
}

echo -en "\e[1;33mRunning hooks..\e[00m "

while read oldrev newrev refname; do
  if [ "$refname" =  "refs/heads/master" ]; then
    hooks=$(git cat-file blob $newrev:.hooks 2>/dev/null)
    if [ -n "$hooks" ]; then
      # Repo-local hooks defined in .hooks.
      for hook in $hooks; do
        run_hook $oldrev $newrev $refname $hook
      done
    fi

    # Global hooks for this repo (ie. set in Gitolite config).
    hooks=$(git config --get hooks.run)
    [ -z "$hooks" ] && continue

    for hook in $hooks; do
      run_hook $oldrev $newrev $refname $hook
    done
  fi
done

echo -e "\e[1;32mDone.\e[00m"
EOF
chmod -v +x local-code/hooks/common/post-receive

Zum Testen habe ich hier ein einfaches Gitrepository mit dem hook Script eingerichtet.
vim conf/gitolite.conf
repo hooktest
RW+ = chr
config hooks.run = runhook.sh

Dieses muss man einchecken.
git add local-code conf/gitolite.conf
git commit -m "add new repo hooktest, add runhoock.sh"
git push
cd ..

Um entsprechend dies einmal zum Testen zu nutzen.

git clone git@server:hooktest
cd hooktest
echo "TEST1" > test
git add test
git commit -m "add test: TEST1"
git push

Quelle:gist.github.com

Der Adaptec Device [9005:028b] (rev 01) hat auf einem Kunden Server immer einen hänger in den Virtuellen Maschinen verursacht. Zigleich traten folgende Fehlermeldung im kernel.Log auf:
[501672.741192] aacraid: Host adapter abort request (0,0,1,0)
[501672.741304] aacraid: Host adapter reset request. SCSI hang ?


Da mir der Contorler schon suspeckt vor kamm und das Problem erst nach einem Jahre langen neustart auftrat habe ich mir den scheduler mal angesehen. Ein gestellt war cfq:
cat /sys/block/sdb/queue/scheduler
noop anticipatory deadline [cfq]

Da der Controller aber immer alles besser weiß habe ich diesen auf noop = no operration umgestellt.
echo noop > /sys/block/sdb/queue/scheduler
cat /sys/block/sdb/queue/scheduler
[noop] anticipatory deadline cfq

Nun lief der reicher wieder flüssig.

Aktuell kann man fast jede Woche auf ssllabs.com nachschauen, ob das „rating“ einer Webseite mal wieder gefallen ist, einer der Server falsch konfiguriert ist oder einfach nur vergessen wurde Dienste neu zu starten. Um dies zu automatisieren hat ssllabs endlich eine api im development Modus freigeschaltet.

Schade das in der api kein Feld ohne das trusted flag hinterlegt ist, so bekomme ich mit meinem CACert leider immer nur ein T.

Ich habe das mal für den Zabbix gescriptet. Alles was man braucht ist folgende ausführbare Datei im Ordner /etc/zabbix/externalscripts/zabbix-check-ssllabs.sh

#!/bin/bash
domain=$1
if [ "$domain" = "" ]; then
	exit 1
fi

tmp=$(mktemp)
#TODO: trap
wget -q -O $tmp "https://api.dev.ssllabs.com/api/fa78d5a4/analyze?host=$domain&publish=On&clearCache=On&all=done"
sed 's/,/\n/g' $tmp | grep grade | awk -F '"' '{print $4}'
rm $tmp

Und natürlich ein Schema das man im Zabbix importieren muss:
Read the rest of this entry »

Wie ich schon vor einigen Jahren geschrieben habe, kann man die SSH fingerprints im DNS hinterlegen, um SSH Verbindungen zu validieren.

# dig -t sshfp blog.chr.istoph.de
;; ANSWER SECTION:
blog.chr.istoph.de. 7199 IN SSHFP 1 1 D931B1124CC5DA23DB2131C62BA9D286081E3EA7
...

Dafür hinterlegt man die Secure Hash Algorithm (SHA) Summen im DNS:
ssh-keygen -r blog.chr -f /etc/ssh/ssh_host_rsa_key.pub
blog IN SSHFP 1 1 d931b1124cc5da23db2131c62ba9d286081e3ea7
blog IN SSHFP 1 2 0fe30bacf0833a9051a74cec431af450ceeca4171b3da5bf0550ada55adadbfa

Jetzt gibt es aber neue Algorithmen die in SSH Einzug erhalten haben.
1: RSA
2: DSA
3: ECDSA
4: ED25519

Da man mit ssh-keygen immer nur einen Key haschen kann und die neue Kurve ED25519 noch nicht von Ubuntu 14.04. unterstützt wird siehe Beispiel:
ssh-keygen -r blog.chr -f /etc/ssh/ssh_host_ed25519_key.pub
export_dns_rr: unsupported algorithm and/or digest_type

So habe ich mir ein Skript geschrieben, das mir alle Fingerprints auf einmal erstellt.

#!/bin/bash

domain="$1"

if [ "$domain" = "" ]; then
	echo $0 domain
	exit 0
fi

function sshfp() {
	a=$1 #algorithmus
	f=$2 #file
	echo $domain IN SSHFP $a 1 $(awk '{print $2}' $f|base64 -d|sha1sum|awk '{print $1}')
	echo $domain IN SSHFP $a 2 $(awk '{print $2}' $f|base64 -d|sha256sum|awk '{print $1}')
}

for f in /etc/ssh/ssh_host_*_key.pub; do
	case "$(echo $f|awk -F '_' '{print $3}')"
	in
	  rsa)
		sshfp 1 $f
		;;
	  dsa)
		sshfp 2 $f
		;;
	  ecdsa)
		sshfp 3 $f
		;;
	  ed25519)		
		sshfp 4 $f
		;;
	esac
done | sort

Die Ausgabe sieht dann folgendermaßen aus:
Read the rest of this entry »

Zum einfach erstellen von DANE DNS Einträge habe ich mir ein Script geschrieben das, dass Zertifikat vom Server (z.b Webserver) abruft und den dazu passenden TLSA record erstellt.

#!/bin/bash
#(c) 2014  Christoph Hueffelmann (blog.chr.istoph.de)
domain=$1 
port=$2
crt=$3

if [ "$port" = "" ]; then
	echo "$0 domain.tld port [path/domain.tld.crt]"
	exit 1
fi
if [ ! -x "/usr/bin/openssl" ]; then
	echo "apt-get install openssl"
	exit 1
fi

if [ "$crt" = "" ]; then
	crt=$(mktemp)
	trap "rm -f $crt" 0 1 2 5 15
	echo QUIT | openssl s_client -servername $domain -connect $domain:$port 2>/dev/null | 
                    sed -ne '/BEGIN CERT/,/END CERT/p' > $crt
fi

#cat $crt
if [ -s $crt ]; then
	echo "_$port._tcp.$domain. IN TLSA 3 0 1 $(cat $crt | openssl x509 -outform DER | 
                                                   openssl sha256 | awk '{print $2}')"
else
	exit 1
fi

exit 0

Alles was man angeben muss ist die Domain und der Port oder optional auch den Pfad zur .crt Datei:
# ./tlsa.sh blog.chr.istoph.de 443
_443._tcp.blog.chr.istoph.de. IN TLSA 3 0 1 253ac080ec87c1a049cc5992e311d3afe39e7554b45ad754438dd7fcaeb22727

Fals man nur den SHA braucht kann man auf folgneden einzeiler verwenden:

echo QUIT | openssl s_client -connect blog.chr.istoph.de:443 | 
sed -ne '/BEGIN CERT/,/END CERT/p' | openssl x509 -outform DER | 
openssl sha256

Anmerken möchte ich natürlich das dies natürlich nicht der weg sein sollte TLSA records für Produktivbetrieb zu erstellen.

[UPDATE 28.01.15]
Das openSSL Kommando ist nun auch mittels der Option -servername SNI fähig.