Kategori Netzwerk

Alle Amazon Web Service EC2 Instanzen rebooten

Freitag, Januar 13th, 2012

Heute musste ich mal alle AWS Instanzen neustarten. Dafür habe ich alle Aktiven Instanzen heraus gegept und in eine TMP Datei geschrieben. Diese habe ich dann zum neustarten der Server verwendet.
[UPDATE] Das gilt natürlich nur dann wenn man auch seien SSH-KEY hinterlegt hat. [/UPDATE]

#!/bin/bash
export EC2_PRIVATE_KEY=$(pwd)/pk-xxx.pem
export EC2_CERT=$(pwd)/cert-xxx.pem
tmp=$(mktemp)
 
ec2-describe-instances | grep INSTANCE | awk '{print $4}' > $tmp
 
while read server; do
        echo "${server}"
	ssh "${server}" "reboot" 1>/dev/null < /dev/null &
	sleep .1
done < $tmp
 
rm $tmp
exit 0

Tinc Debugging

Donnerstag, Januar 5th, 2012

Um Tinc besser Debuggen zu können kann man das syslog einfach in den Hintergrund schreiben und mittels killall -USR2 tincd anstupsen. Das sieht dann folgender massen aus.

tail -F /var/log/syslog &
...
killall -USR2 tincd
srv01 tinc.vpn[28369]: Statistics for Linux tun/tap device (tun mode) /dev/net/tun:
srv01 tinc.vpn[28369]: total bytes in: 294
srv01 tinc.vpn[28369]: total bytes out: 294
srv01 tinc.vpn[28369]: Nodes:
srv01 tinc.vpn[28369]: srv02 at 1.2.3.4 port 655 cipher 91 digest 64 maclength 4 compression 0 options d status 003a nexthop srv01 via srv01 pmtu 1451 (min 1451 max 1451)
srv01 tinc.vpn[28369]: End of nodes.
srv01 tinc.vpn[28369]: Edges:
srv01 tinc.vpn[28369]: srv02 to srv01 at 1.2.3.4 port 655 options d weight 328
srv01 tinc.vpn[28369]: srv01 to srv02 at 1.2.3.5 port 655 options d weight 328
srv01 tinc.vpn[28369]: End of edges.
srv01 tinc.vpn[28369]: Subnet list:
srv01 tinc.vpn[28369]: 192.168.0.0/24#10 owner srv01
srv01 tinc.vpn[28369]: End of subnet list.

Mit fg und STRG + C kann man das teil -F wieder aus dem Hintergrund holen und beenden.

Tinc und GIT

Sonntag, Januar 1st, 2012

Tinc ist im gegenstart zu OpenVPN eine mash vpn. Damit dies funktioniert müssen aber auf jemden Server die öffentlichen Schüssel/Konfigurationsdateien bekannt sein. Um diese Schlüssel zu verteilen verwende ich GIT.

Hier ein aufbau zwischen zwei Servern (SRV01/SRV02). Jeweils habe den Ordner /opt/git/ erstell und das Git ausgeschekt. Den VPN Ordner habe ich dann mittels eines Symlinks ins /etc/tinc Verzeichnis gelinkt.
ln -s /opt/git/vpn.tinc/vpn /etc/tinc/vpn

Folgende Daten und Ordner befinden sich in meinem Git. Mittels der .d Verzeichnisse werden die einzelne Dateien auf den Servern gelinkt (siehe unten).
/etc/tinc/vpn/
hosts
hosts/srv01
hosts/srv02
tinc.conf.d
tinc.conf.d/srv01.conf
tinc.conf.d/srv02.conf
up.d
up.d/srv01-up
up.d/srv02-up
down.d
down.d/down

Die Dateien im einzelnen.
--- SRV01 ---
hosts/srv01:

Name = srv01
Address = srv01.chr.istoph.de
Cipher = blowfish
Digest = sha1
IndirectData = yes
Subnet = 10.8.0.1/32
Subnet = 192.168.0.1/24

Wichtig: bei Subnet muss einmal die Lokale Adresse auf die gelauscht werden soll mit /32 angegeben werden. Das zweite Subnet ist nur beispielhaft für weiteres netz das sich hinter SRV01 befindet.

tinc.conf.d/srv01.conf:

Name = srv01
AddressFamily = ipv4
BindToInterface = eth0
ConnectTo = srv02
Device = /dev/net/tun
Mode = router
KeyExpire = 3600
PrivateKeyFile = /etc/tinc/vpn/rsa_key.priv

up.d/srv01-up:

#!/bin/bash
ip addr add 10.8.0.1/24 dev vpn
ip link set vpn up

down.d/down:

#!/bin/bash

Auf SRV01 müssen dann natürlich nur folgende Symlinks erstellt werden.
ln -s tinc.conf.d/srv01.conf tinc.conf
ln -s up.d/srv01-up tinc-up
ln -s down.d/down tinc-down

--- SRV02 ---
hosts/srv02:

Name = srv02
Address = srv02.chr.istoph.de
Cipher = blowfish
Digest = sha1
IndirectData = yes
Subnet = 10.8.0.2/32

tinc.conf.d/srv02.conf:

Name = srv02
AddressFamily = ipv4
BindToInterface = eth0
ConnectTo = srv01
Device = /dev/net/tun
Mode = router
KeyExpire = 3600
PrivateKeyFile = /etc/tinc/vpn/rsa_key.priv

up.d/srv02-up:

#!/bin/bash
ip addr add 10.8.0.2/24 dev vpn
ip link set vpn up

ln -s tinc.conf.d/srv02.conf tinc.conf
ln -s up.d/srv02-up tinc-up
ln -s down.d/down tinc-down

--- END ---

Nach dem die Dateien angelegt sind können auf dem jeweiligen Server (SRV01 / SEV02), die Keys erstellt werden.
tincd --generate-keys=4096 -n vpn

Dies Legt den Privaten schlüssel rsa_key.priv an und legt den Öffentlichen Schlüssel in die host/srv01 Datei.

Vor dem Starten von Tinc müssen die up/down Scripte noch Ausführungsrechte auf den Jeweiligen Servern bekommen.
chmod +x up.d/srv*
chmod +x down.d/down

Nun können wir alles im GIT einchecken. Nicht vergessen nach dem einchecken von SRV01 auf SRV02 zu pullen und erst dann die Dateien anzulegen um sie zu puschen.
git add hosts/srv01 tinc.conf.d/srv01.conf up.d/srv01-up down.d/down
git commit -m "tinc: add srv01"
git puch

Wichtig hierbei ist den Privaten Schlüssel rsa_key.priv nicht einzucken. Auch aus Backup gründen macht dies keinen Sinn da dieser immer wieder neu erstellt werden kann.

Bei Ubuntu Systemen muss in der Datei /etc/tinc/nets.boot der Name des zu startenden Netzwerkes eingetragen werden. In unserem Fall VPN.
## This file contains all names of the networks to be started on system startup.
vpn

AWS Amazon Web Service EC2 Scripten

Dienstag, Dezember 20th, 2011

Für einen Lasttest habe ich etliche AWS Micro Instanzen mit Ubuntu 10.4 benötigt, die alle vorkonfiguriert werden mussten. Da man aber nicht Tausend Instanzen von Hand Einrichten und Konfigurieren will musste mal wieder ein Script her.

Als erstes braucht man die ec2-api-tools
sudo apt-get install ec2-api-tools

Dann habe ich ein Start Script Namens run-file.sh geschrieben, das z.b. so aussieht:
#!/bin/bash

apt-get update
apt-get install -y apache2-utils
ab http://blog.chr.istoph.de/

Dann habe ich die Instanzen mittels eine for Schleife gestartet.
for i in {1..1000}; do
ec2-run-instances ami-e52ce68c --instance-type t1.micro --region us-east-1 --key ca -K pk-xxx.pem -C cert-xxx.pem -user-data-file run-file.sh
done

Das starten der Instanzen sollte nicht mittels & in den Hintergrund geschoben werden, da das Programm ec2-run-instances ein sehr Speicherfressendes Java Programm ist.

Nachdem man jetzt die 1000 Instanzen eine Weile laufen gelassen hat muss man diese auch wieder beenden. Dazu kann man sich folgendermaßen alle Instanzen anzeigen:
ec2-describe-instances -K pk-xxx.pem -C cert-xxx.pem

Dem endsprechen kann man auch ALLE existierende Instanzen gelöscht werden:
ec2-terminate-instances -K pk-xxx.pem -C cert-xxx.pem $(ec2-describe-instances -K pk-xxx.pem -C cert-xxx.pem | grep INSTANCE | awk '{print $2}')

Quelle: help.ubuntu.com
uec-images.ubuntu.com

OpenSSH Fingerprinte im DNS

Sonntag, November 27th, 2011

Jetzt habe ich endlich mal eine einfache Anleitung gefunden um OpenSSH Fingerprinte im DNS zu hinterlegen (RFC4255).

Denn ssh-keygen kann diereckt den für BIND nötigen SSHFP record erstellen.

root@ns01:~# ssh-keygen -r ns01.caix.de -f /etc/ssh/ssh_host_rsa_key.pub
ns01.caix.de IN SSHFP 1 1 e208441777cba0459c52e8680b617b254183f711
root@ns01:~# ssh-keygen -r ns01.caix.de -f /etc/ssh/ssh_host_dsa_key.pub
ns01.caix.de IN SSHFP 2 1 0476a2a57fb720fbee586b78e28490929501d8c6

Nach dem veröffentlichen im DNS kann mal den Record mit dig abrufe.
dig -t SSHFP ns01.caix.de

;; ANSWER SECTION:
ns01.caix.de. 7200 IN SSHFP 1 1 E208441777CBA0459C52E8680B617B254183F711
ns01.caix.de. 7200 IN SSHFP 2 1 0476A2A57FB720FBEE586B78E28490929501D8C6

Testen kann mal das ganze dann mit der Option VerifyHostKeyDNS und -v für den Debug mode. Die zwei entscheiden Zielen habe ich unten aufgeführt.

ssh root@ns01.caix.de -o VerifyHostKeyDNS=yes -v
...
debug1: found 2 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
...

Quelle: bd.hauke-lampe.de

Das STW Aachen und der NWR

Samstag, Mai 7th, 2011

Vor gut einem Jahr beschloss das STW-Aachen massive Umbaumaßnamen in unserem Wohnheim durchzuführen. Dazu zählen der Umbau der Heizung und die Sanierung der Fassade, was zur folge hatte das die gesamte 12. Etage, in der sich unser Netzwerkraum befindet, umgebaut wurde.

Hier aber erst mal ein par Fotos wie es vor dem Umzug aus sah. Da hatten wir einen Schrank in dem die Server standen und noch die alten 100Mbit HP Switche im Netzwerkschrank.

Dann bekamen wir den Cisco Catalyst 4006 mit 3x 48Port 100Mbit, 1x 48Port 1Gbit. Was gar nicht so schleicht war da die Stromaufnahme im Schrank sang und wir über die 3 Netzteile mehrfach redundant angebunden waren. Leider mussten wir für die Zeit die Hidden Bridge zurück bauen.

Die werten Hobbyarchitekten kamen auf die Idee den Raum kleiner zu mache. Als wir die Pläne zu Gesicht bekamen stellen wir fest, das so wie sie es geplant haben, wir die Tür vom Netzwerkschrank nicht mehr öffnen hätten können. Die Hobbyarchitekten meinen das wir den Schrank doch einfach verschieben sollten. Leider hatten sie nicht an die Kabel gedacht die durch den Fußboden in die Zimmer verteilt werden. Dennoch haben wir den Vorschlag gemacht das wir den Schrank drehen können.

Das sah dann so aus. Unser LWL Kabel das während den Bauarbeiten schon mal durchtrennt wurden haben wir diesmal Überall markiert.

Dann gingen die Abreißarbeiten auf der 12. los. Die Wende wurden eingerissen dafür haben wir den Schrank mit Panzerband angeklebt.

Da wir auf den Bauleitersitzungen beklagt haben, dass wir unsere Server Infrastruktur zum betreiben des Internets benötigen, haben wir eines der Schimmel Zimmer bekommen.

Dumm war nur das unsere Server die Luft so stark getrocknet haben das der Schimmel verschwand und wir ins nächste Schimmel Zimmer umziehen mussten.

Dieses Zimmer durften wir dann mit der Firma die die Fenster austauschte teilen. Nicht nur das die Tür dieses Zimmers den ganz Tag offen stand. Nach dem die Bauarbeiter gegangen sind haben sie nicht mal abgeschlossen. Gut nur das nix verschwunden ist.

Derweil tat sich einiges im Serverraum, die Wende wurden gezogen und der Estricht wurde gelegt.

Nach dem an den Plänen dann wieder Heruntergespielt wurde und wir nun wieder eine Tür nicht öffnen konnten, mussten wir den Schrank wieder zurückdreht. Für alle Fachmänner: der Schrank war voll gepecht und im betrieb. Da dreht sich nicht nur der Schrank sondern auch der Magen.

Weitere Monate zogen ins Land und der Raum wurde gestrischen und die Klima installiert. Leider wurde vergessen sie zu befüllen.

Dann war es endlich soweit. Die Server konnten endlich in Ihr neues Zuhause umziehen. Aber fast wäre es nicht dazu gekommen, denn die oben erwähnten Hobbyarchitekten haben für die Heizungsanlage für 18.000€ zufiel Kabel ziehen lassen aber nur eine Steckdose im Netzwerkraum, direkt an der Tür Hinterlassen. Gütigerweise haben wir nach mehrfachen Betteln jetzt doch noch eine bekommen.

Das war nur ein kleiner Teil was wir mit dem Serverraum erlebt haben. Ein besonderer Gruß gilt an dieser stelle aber dem Hobbyarchitekten. Der alleine schon, durch die verzögert des Baus 1,5 Millionen € für das Gerüst ausgegeben hat, 18.000 € für die Ansteuerung der Heizung in den Sand setzte und die Steckdosen im EDV Raum vergessen hat. Das da noch einiges nicht an die Öffentlichkeit gekommen ist müsste einigen klar sein. In der freien Wirtschaft hätte ich so jemanden schon lange vor die Türe gesetzt.

DNS Antworten zu groß

Freitag, Mai 6th, 2011

Heute hatte ich ein sehr seltsames Problem mit DNS. Da ich auf google docs nicht mehr zugreifen konnte und Chromium mir folgende Antwort lieferte: Fehler 105 Die DNS Adresse des Servers kann nicht aufgelöst werden.

Ein dig auf die Domain ergab das die anfrage zurückgewiesen worden ist und eine TCP anfrage gestellt wurde. Dies lies mich darauf schlissen das Bind nicht auf den TCP Port lissent, bzw. eine FW dazwischen war.
dig @192.168.0.1 docs.google.com
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.7.0-P1 <<>> @192.168.0.1 docs.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Nach dem ich die Firewall auch für TCP geöffnet habe kamm auch die folgende Große Antwort zurück. Das erklärte auch warum dies vorher noch nicht aufgetreten ist.

; <<>> DiG 9.7.0-P1 <<>> @192.168.0.1 docs.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37063
;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;docs.google.com. IN A

;; ANSWER SECTION:
docs.google.com. 84462 IN A 74.125.230.103
docs.google.com. 84462 IN A 74.125.230.104
docs.google.com. 84462 IN A 74.125.230.105
docs.google.com. 84462 IN A 74.125.230.106
docs.google.com. 84462 IN A 74.125.230.107
docs.google.com. 84462 IN A 74.125.230.108
docs.google.com. 84462 IN A 74.125.230.109
docs.google.com. 84462 IN A 74.125.230.110
docs.google.com. 84462 IN A 74.125.230.111
docs.google.com. 84462 IN A 74.125.230.96
docs.google.com. 84462 IN A 74.125.230.97
docs.google.com. 84462 IN A 74.125.230.98
docs.google.com. 84462 IN A 74.125.230.99
docs.google.com. 84462 IN A 74.125.230.100
docs.google.com. 84462 IN A 74.125.230.101
docs.google.com. 84462 IN A 74.125.230.102

;; AUTHORITY SECTION:
. 26616 IN NS a.root-servers.net.
. 26616 IN NS b.root-servers.net.
. 26616 IN NS c.root-servers.net.
. 26616 IN NS d.root-servers.net.
. 26616 IN NS e.root-servers.net.
. 26616 IN NS f.root-servers.net.
. 26616 IN NS g.root-servers.net.
. 26616 IN NS h.root-servers.net.
. 26616 IN NS i.root-servers.net.
. 26616 IN NS j.root-servers.net.
. 26616 IN NS k.root-servers.net.
. 26616 IN NS l.root-servers.net.
. 26616 IN NS m.root-servers.net.

;; Query time: 0 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri May 6 11:17:03 2011
;; MSG SIZE rcvd: 500

RRD Graphen über SNMP erstellen

Sonntag, Januar 30th, 2011

Hier Dokumentire ich mal wie wir im Wohnheim den Cisco Catalist 4006 über SNMP abfragen um RRD Graphen zu erstellen. Zuerst muss man auf den Cisco natürlich SNMP einschalten und ein Passwort Sätzen.

snmp-server community password RO
snmp-server enable traps tty

Als erstes müssen vollende Pakete installiert werden:
apt-get install php-cli snmp rrdtool

Dann habe ich ein Script geschrieben das die insgesamt 195 Port abfragt.

 
#!/usr/bin/php5
<?
 
//CISCO
for($i=1;$i<=195;$i++)
{
// RRD ERSTELLEN
   //system("rrdtool create bandwidth-". $i .".rrd --start N DS:in:COUNTER:600:U:U
DS:out:COUNTER:600:U:U RRA:AVERAGE:0.5:1:432");
 
// RRD LOGGEN
  system("/usr/bin/rrdupdate /usr/local/rrd/bandwidth-". $i .".rrd N:
`/usr/bin/snmpget -v1 -c password 192.168.1.1 -Oqv IF-MIB::ifInOctets.". $i ."`:
`/usr/bin/snmpget -v1 -c password 192.168.1.1 -Oqv IF-MIB::ifOutOctets.". $i ."`");
 
// RRD GRAPH
  system("/usr/bin/rrdtool graph /usr/local/rrd/img/bandwidth-". $i .".png
-a PNG -w 500 -h 150 -M -s -129600 -v \
`/usr/bin/snmpget -v1 -c password 192.168.1.1 -Oqv IF-MIB::ifDescr.". $i ."` \
    'DEF:in=/usr/local/rrd/bandwidth-". $i .".rrd:in:AVERAGE' \
    'DEF:out=/usr/local/rrd/bandwidth-". $i .".rrd:out:AVERAGE' \
    'CDEF:kbin=in,1024,/' \
    'CDEF:kbout=out,1024,/' \
    'AREA:in#00FF00:Bandwidth In' \
    'LINE1:out#0000FF:Bandwidth Out\j' \
    'GPRINT:kbin:LAST:Last Bandwidth In\:    %3.2lf KBps' \
    'GPRINT:kbout:LAST:Last Bandwidth Out\:   %3.2lf KBps\j' \
    'GPRINT:kbin:AVERAGE:Average Bandwidth In\: %3.2lf KBps' \
    'GPRINT:kbout:AVERAGE:Average Bandwidth Out\:%3.2lf KBps\j'");
}
?>

Das ganze sieht dann so aus, hier ist der Aktelle Graph des Netzwerk Trafik des Wohnheims:
network traffic

Nginx vs Apache2

Montag, November 22nd, 2010

Es ist soweit, meine Blog wurde jetzt auch auf Nginx umgestellt. Aber warum? Erstmal habe ich immer noch einen Apache2 im Einsatz, um aber die Auslieferung der Webseite zu bescheinigen habe ich einen Nginx Cash Proxy davor geschaltet. Was Bringt das...

apache2 auf VMware Server, 2x 2,2GHz Opteron mit 8GB DDR400 Ram in Nürnberg:

Ladezeit: 5,08sec

apache2 auf Xen, Intel® Core™ i7-920 Quad-Core inkl. Hyper Hetzner in Falkenstein 8 GB DDR3 RAM:

Ladezeit: 2,56sec

Nginx auf Xen, Intel® Xeon Server Prozessor 2x Quad Core CPU 12 GB DDR3 in Frankfurt :

Ladezeit: 0,97sec

Wie man anhand der Graphen erkennen kann, konnte ich die Auslieferung von 5,08sec mit besserer Hardware und besserer Virtualisierung auf knapp die Hälfte auf 2,56sec reduzierten. Mit Nginx anstatt Apache2 nochmal um den Faktor 5 auf 0,97sec.

Die Berechnungen habe ich durch die Tools von Google Chrome machen lassen, alternativ kann man aber auch das Firebug Add-on nutzen. Wer das selber einmal nachvollziehen will, kann blog.chr.istoph.de (Nginx) und blog.christoph-hueffelmann.de (Apache2) an surfen.

MySQL Unix Socket weiterleiten

Samstag, November 13th, 2010

Wenn man bei einer LAMP System den Datenbankserver auf eine extra Maschine legen muss, hat man dank PHP etwas Stress mit dem unterschied zwischen localhost und 127.0.0.1 bzw ::1. Das liegt daran der UNIX Socket bei mein match auf localhost fest einkompiliert ist.

Mit socat kann man den Unix Socket zum Glück umleiten:
socat UNIX-LISTEN:/var/lib/mysql/mysql.sock,fork,user=mysql,group=mysql,mode=777 TCP:localhost:3306 2> /dev/null &

Mit rinetd kann man diese dann auf eine IP Weiterleiten.

openvpn easy-rsa

Donnerstag, November 4th, 2010

OpenVPN bringt mit easy-rsa ein sehr einfach zu bedienende Zertifikats Erstellung mit. Wenn es allerdings zu Fehlern kommt, sind die Fehler Bescheinigungen sehr mager. So kam es während des erstellen eines Zertifikates nach der Anleitung von howtoforge.com zu folgenden Fehler.

cp -R /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn

vim /etc/openvpn/easy-rsa/2.0/vars

cd /etc/openvpn/easy-rsa/2.0/
chmod +rwx *
source ./vars
./clean-all
./pkitool --initca

Error:
string is too long, it needs to be less than 40 bytes long

Der Fehler war das ich in der easy-rsa/2.0/vars zu lange werte für das Zertifikat angegeben habe. Dann war das Problem das man den Prozess ab
source ./vars
./clean-all
./pkitool --initca

und nicht nur den letzten schritt...

Umbau der Nameserver Struktur

Montag, Oktober 11th, 2010

Nach dem Vorfall bei der DENIC am 12. Mai 2010 habe ich nun die komplette Nameserver Struktur im laufenden betrieb umgebaut. Ohne das es zu Ausfällen kam sind nun alle Domains die bei mir gehostet sind von der Root Zohne aus gesehen über zwei eigenständige TLDs erreichen. Dabei verfügen chrnet.de als auch chrnet.eu über eigene GLUE Rekords. Außerdem stehen die Nameserver an zwei separate Standpunk, Nürnberg und Frankfurt.

Root Zone             .
		   /     \
TLD		.de      .eu
		 /         \
DOMAIN	      chrnet     chrnet
                /\          /\
	       /  \	   /  \
NAMESERVER  ns01 ns02     ns01 ns02
	       \               /
                \             /
DOMAIN        blog.chr.istoph.de

Glue IPv6 record

Freitag, Juni 25th, 2010

Ich bin nun jetzt schon seit 2008 dabei mich mit IPv6 zu beschäftigen. Jetzt habe ich endlich den ersten glue IPv6 record erstellt. Im Zuge dessen ist jetzt auch mein Blog wieder über IPv6 erreichbar. Nach einer weiteren Testphase werden dann auch weitere Kundendomains folgen.

CDP (Cisco Discovery Protocol)

Mittwoch, Februar 10th, 2010

Da nun endlich die CISCO 4006 läuft habe ich den wurde mir mitgeteilt das ich doch mal CDP Konfigurieren soll. Standardmäßig ist dies auf allen Prots eingestellt und gib darüber Auskunft welche Geräte an welchem Port hängen.

Lustig ist das man dies auch auf Normalen Linux Maschine zum laufen bekommt. Hier eine Anleitung wie es unter Ubuntu geht und welche Informationen man bekommt.
sudo apt-get install build-essential libpcap-dev libpcap0.8-dev
wget -c http://snar.spb.ru/prog/cdpd/cdpd-1.0.4.tgz
md5sum cdpd-1.0.4.tgz # ( 7fb767a2e1644456c817bf8477406117 )
tar xfz cdpd-1.0.4.tgz
cd cdpd-1.0.4
./configure
make all
sudo mkdir -p /usr/local/man/man8
sudo cp cdpd.8 /usr/local/man/man8
sudo cp cdpd /usr/local/sbin
sudo /usr/local/sbin/cdpd -a

Ausgabe Switch:
switch#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone

Device ID Local Intrfce Holdtme Capability Platform Port ID
hostname Fas 2/1 167 H i686 eth0

switch#show cdp neighbors detail
-------------------------
Device ID: hostname
Entry address(es):
IP address: 192.168.0.1
Platform: i686, Capabilities: Host
Interface: FastEthernet2/1, Port ID (outgoing port): eth0
Holdtime : 149 sec

Version :
Linux 2.6.24-26-server #1 SMP Tue Dec 1 19:19:20 UTC 2009

Quelle: ubuntuforums.org

Heute, WLAN über 6,7km

Mittwoch, September 30th, 2009

# ping 10.0.0.1 -c 20
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
...
64 bytes from 10.0.0.1: icmp_seq=15 ttl=64 time=5.08 ms
64 bytes from 10.0.0.1: icmp_seq=16 ttl=64 time=5.04 ms
64 bytes from 10.0.0.1: icmp_seq=17 ttl=64 time=5.21 ms
64 bytes from 10.0.0.1: icmp_seq=18 ttl=64 time=4.98 ms
64 bytes from 10.0.0.1: icmp_seq=19 ttl=64 time=9.55 ms
64 bytes from 10.0.0.1: icmp_seq=20 ttl=64 time=5.16 ms

--- 10.0.0.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19010ms
rtt min/avg/max/mdev = 4.902/5.862/9.558/1.401 ms

wlan_6km

Kein youtube.com mehr…

Sonntag, Juni 14th, 2009

Wie schon basicthinking.de berichtet hat ist Youtube zumindest was Musik angeht der groessten Flops des vergangenen Jahrzehnts.

Bei uns in der Kellerbar haben wir auch feststellen müssen, dass die Qualität der Songs unsere hochwertige Anlage quält und beschlossen youtube.com mal eben zu sperren. Da wir sowieso eine hidden briege einsetzen war dies ganz einfach mit einer iptabels regel zu definieren.

iptables -A FORWARD -s 10.0.0.2 -d www.youtube.com -j DROP
iptables -A FORWARD -s 10.0.0.2 -d youtube.com -j DROP

Quelle: Fex

openNMS

Mittwoch, Mai 13th, 2009

Ich habe mich die tage auch mal an openNMS versucht und weiß jetzt warum es so wenige Einsätzen, obwohl es eine Mächtiges Applikation ist. Die Installation war nicht gerade ein Kinderspiel.

Zu erst hatte ich unter Ubuntu 9.04 ein Abhängigkeit Problem. Dies Konnte ich nur durch hinzufügen der backports quellen erreichen, dar das Parket jrrd nicht aufgelöst werden konnte:
deb http://mirror.bauhuette.fh-aachen.de/ubuntu/ jaunty-backports main restricted universe multiverse
deb-src http://mirror.bauhuette.fh-aachen.de/ubuntu/ jaunty-backports main restricted universe multiverse

Dann konnte ich den Installer nur mit der -l Option aufrufen bekam aber immer noch folgende Fehlermeldung:
/usr/share/opennms/bin/install -dis -l /usr/lib/jni:/usr/lib
...
Configures PostgreSQL tables, users, and other miscellaneous settings.

- searching for jicmp:
- trying to load /usr/lib/jni/libjicmp.so: OK
- searching for jrrd:
- trying to load /usr/lib/jni/libjrrd.so: OK
- checking database version... Exception in thread "main" java.sql.SQLException: Could not get an administrative connection to the database. Is the database running, listening for TCP connections, and allowing us to connect and authenticate from localhost? Tried connecting to database specified by data source SimpleDataSource[URL='jdbc:postgresql://localhost:5432/template1', driver class='org.postgresql.Driver', properties: user='postgres', password='']. Original error: org.postgresql.util.PSQLException: FATAL: fehlende oder fehlerhafter pg_hba.conf-Datei
at org.opennms.netmgt.dao.db.InstallerDb.rethrowDatabaseConnectionException(InstallerDb.java:2214)
at org.opennms.netmgt.dao.db.InstallerDb.initializeAdminConnection(InstallerDb.java:2191)
at org.opennms.netmgt.dao.db.InstallerDb.getAdminConnection(InstallerDb.java:2180)
at org.opennms.netmgt.dao.db.InstallerDb.databaseCheckVersion(InstallerDb.java:1526)
at org.opennms.install.Installer.install(Installer.java:194)
at org.opennms.install.Installer.main(Installer.java:778)
Caused by: org.postgresql.util.PSQLException: FATAL: fehlende oder fehlerhafter pg_hba.conf-Datei
at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:275)
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:94)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:65)
at org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:116)
at org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:30)
at org.postgresql.jdbc3.Jdbc3Connection.(Jdbc3Connection.java:24)
at org.postgresql.Driver.makeConnection(Driver.java:369)
at org.postgresql.Driver.connect(Driver.java:245)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
at org.opennms.netmgt.dao.db.SimpleDataSource.getConnection(SimpleDataSource.java:79)
at org.opennms.netmgt.dao.db.InstallerDb.initializeAdminConnection(InstallerDb.java:2189)
... 4 more

Hier kommt der Grund warum ich Java Fehlermeldungen nicht mag. Sie sind einfach zu lang und dadurch unübersichtlich. Trust ist das verfahren was openNMS nutzt. Zudem darf es nicht mehr 127.0.0.1/255.255.255.255 heißen.
host all all 127.0.0.1/32 trust
Anschließend Postgres Neustarten: /etc/init.d/postgresql-8.3 restart
und dann lief bei mir der Installer.

D-Link Switch mit VLAN problem

Freitag, März 6th, 2009

Unser neues D-Link Switch DGS1248T bricht komplett zusammen beim einrichten eines VLANs.

ftp

Mittwoch, November 12th, 2008

Da wollte ich doch ein par Dateien von einem Ubuntu Rechner auf einen Vista Rechner Kopieren. Und dachte da müsste doch ohne weiters auch per FTP gehen. Also kopierte ich fleißig von ext3 nach nfts über ftp und musste feststellen das auf dem Vista Rechner die Dateien nach genau 4GiB abgebrochen wurden.
Also ob diese magische Größe mit fat32 nicht schon Problem genug war.

Keine Blacklist für 4096bit Keys

Samstag, Oktober 18th, 2008

Ich weiß ja das 4096bit große Keys übertrieben sind. Aber das ist doch kein Grund dafür keine Blacklist anzulegen. So bekam ich immer die folgende Fehlermeludung wenn ich die OpenVPN verbindung starten wollte:

user@server:~# /etc/init.d/openvpn start
* Starting virtual private network daemon.
WARN: could not open database for 4096 bits. Skipped
* client (OK) [ OK ]

Da ich mir ja sicher bin das mein Key richtig ist habe ich einfach eine lehre Blacklist angelegt.
touch /usr/share/openssl-blacklist/blacklist.RSA-4096

user@server:~# /etc/init.d/openvpn stop
* Stopping virtual private network daemon. [ OK ]
user@server:~# /etc/init.d/openvpn start
* Starting virtual private network daemon.
* client (OK)

Quelle: forum.ubuntuusers.de