Kategori Computer

zabbix check sshkey

Mittwoch, Mai 20th, 2015

passwd-checksumBei Zabbix ist standardmäßig dabei, dass Checksumme von der /etc/passwd erstellt werden.

Da mir dies aber nicht reicht, habe ich ein Check geschrieben, der auch die
~/.ssh/authorized_keys
prüft. Hier braucht man lediglich mittels
apt-get install zabbix-check-sshkey
das Paket zu installieren, das sich in meinem repository befindet. Das Zabbix Template wird direkt mitgeliefert und befindet sich dann in
/usr/share/doc/zabbix-check-sshkey/zabbix_check_sshkey_template.xml
und muss auf dem Zabbix Server importiert werden.

Migrieren einer root Partition im live betrieb zu einer lv

Samstag, April 25th, 2015

Für die Migration der Root Partition in ein LVM System musste ich zunächst erst mal lvm2 installieren. Dann habe ich die Partitionen angepasst.

apt-get install lvm2
fdisk /dev/sdb

Sodass meine Partition wie folgt aussieht:
Gerät boot. Anfang Ende Blöcke Id System
/dev/sdb1 2048 102658935 51328444 8e Linux LVM

Dann habe ich das LVM eingerichtet, das LV für das System angelegt und ext4 formatiert:
pvcreate /dev/sdb1
vgcreate vg /dev/sdb1
lvcreate -L system -n 40G vg
mkfs.ext4 /dev/mapper/vg-system

Anschließend konnte ich das LV mounten und mittels Rsync alle Daten kopieren. Mittels der rsync Option „x“ konnte ich /mnt und alle weiteren Filesysteme auschließen.
mount /dev/mapper/vg-system /mnt
rsync -ravPzx / /mnt/

Dann habe ich die fstab angepasst, indem ich mit blkid die neue UUID herausgesucht habe.
blkid
/dev/mapper/vg-system: UUID="ec17cda6-5809-47f1-8a62-f8c47c7103be" TYPE="ext4"
...
vim /mnt/etc/fstab
UUID=ec17cda6-5809-47f1-8a62-f8c47c7103be / ext4 errors=remount-ro 0 1

Dann habe ich mir noch eine chroot gebastelt.
mount --bind /boot /mnt/boot
mount --rbind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount -t proc none /mnt/proc
chroot /mnt

Und darin die initramfs und grub neu gebaut.
update-initramfs -u
update-grub

Dann habe ich die chroot wieder verlassen und zur Sicherheit noch einmal MySQL gestoppt und nur dies noch mal synchronisiert.
/etc/init.d/mysql stop
rsync -avP /var/lib/mysql/ /mnt/var/lib/mysql

reboot
Nach dem abschließenden Reboot ist das System auf der neuen Festplatte wieder hochgekommen.

howto enable cisco remote loggin

Freitag, April 17th, 2015

Um mitzubekommen welche Kable bzw. welche Portds am cisco Switch aktiviert werden leiten wir die Evends an einen Remote Server weiter.

An diesen haben wir lediglich in der /etc/rsyslog.conf das udp Modul aktiviert.
# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

In der firewall den Port 514 geöffnet und den Dinst neugestartet.
/etc/init.d/rsyslog restart

Auf dem cisco switch habe ich dann den Server angegeben an den die Login daten gesendet werden sollen.
c6506(config)#logging 10.0.0.2

Und die Interfaces mitgeteilt das auf diesen mitgeloogt werden soll.
c6506(config-if-range)#interface range Gi1/1-48
c6506(config-if-range)#logging event link-status

In /var/log/syslog sieht das dann so aus:
%LINK-3-UPDOWN: Interface GigabitEthernet1/48, changed state to down
%LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet1/48, changed state to down

gitolite mit git hooks

Dienstag, März 31st, 2015

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

system hänger mit hardware raid-controller

Montag, Februar 9th, 2015

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.