Monats Archiv: März 2017

  • -

Zentralisierte Sicherung der Konfiguration von HP ProCurve Switchen

Kategorie : News

Es ist ein bisschen umständlich, wenn man mehrere HP ProCurve Switche im Netzwerk hat und deren Konfiguration regelmäßig sichern möchte.

Deswegen habe ich mir eine zentralisierte Sicherung eingerichtet:

Dazu benötigt man einen Linux-Server (in meinem Fall CentOS 6) mit dem TFTP-Server-Dienst und der Scriptsprache expect.

Die Skriptsprache expect dient zur Automatisierung von interaktiven Aufgaben unter Unix. Es handelt sich um eine Erweiterung der Skriptsprache TCL für interaktive Anwendungen wie telnet, ftp, passwd, fsck, rlogin, ssh und andere.

Zuerst installiert man den TFTP-Server:

yum install syslinux tftp-server -y

Der TFTP-Servers wird mit Hilfe des xinetd-Daemon gestartet. Hierzu passt man die Konfigurationsdatei des Daemon (/etc/xinetd.d/tftp) wie folgt an:

# default: off
# description: The tftp server serves files using the trivial file transfer \
#       protocol.  The tftp protocol is often used to boot diskless \
#       workstations, download configuration files to network-aware printers, \
#       and to start the installation process for some operating systems.
service tftp
{
        disable = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -c -s /var/lib/tftpboot
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

Der Ordner, auf den nun der TFTP-Server verwiest (Upload- und Download-Ordner ist hier in der Zeile server_args angegeben (/var/lib/tftpboot).

Anschließend passt man noch iptables an.

Ob nun xinetd und damit tftpd immer aktiv bleiben soll oder nicht, bleibt jedem selber überlassen.

Weiterführende Information zur Konfiguration siehe https://dokuwiki.nausch.org/doku.php/centos:pxe:tftp

Nun installiert man noch expect:

yum install expect -y

Weiterführende Informationen zu expect siehe http://mikiwiki.org/wiki/expect

Damit die Konfig-Dateien der Switche auch noch zentral gelagert werden, wo auch andere Konfig-Dateien sich befinden, habe ich noch einen Ordner /BackupConfigs angelegt. Im Folgenden wird via Samba eine Windows-Freigabe in diesen Ordner gemounted. In dieser Samba-Freigabe habe ich noch eine leere Datei chkfile angelegt.

Nun kommen wir zum eigentlichen Backup-Prozess. Dazu habe ich zwei Scripte backup.sh, switch-backup2.sh) und eine Datei, welche die Netzwerk-Adressen, Username und Passwort enthält, switch.list), geschrieben. Diese drei Dateien liegen alle in einem Verzeichnis.

Alle Parameter, die anzupassen sind, sind im Folgenden rot und fett markiert.

backup.sh:

Dieses Script macht folgendes:

  • Es liest die Datei switch.list zeilenweise aus,
  • übergibt die entsprechenden Parameter an das Script switch-backup2,
  • mountet eine Samba-Freigabe in den Ordner /BackupConfigs (wurde vorher angelegt), auf der die Konfig-Dateien kopiert werden,
  • schaut nach, ob die Samba-Freigabe gemountet ist, indem geprüft wird, ob die Datei chkfile existiert,
  • kopiert die Konfig-Dateien vom TFTP-Ordner (hier /var/lib/tftpboot) in die Samba-Freigabe,
  • löscht Konfig-Dateien, die älter sind als 60 Tage,
  • unmounted die Samba-Freigabe wieder und
  • versendet eine Mail.

 

#!/bin/bash

#Read Date
d=`date +%d-%m-%Y`

date +"Startzeit: %d.%m.%Y %H:%M"  > mail.txt
echo " " >> mail.txt
echo " " >> mail.txt
echo "Zugriff auf folgende Switche:" >> mail.txt

#Read each line in switch.list

while read line
do
      case "$line" in
            "#"*) ;;
            *) zeile=$line;;
      esac

      #Split each line into IP, Name, User, Password
      IFS=","
      set - $zeile
      if [ -n "$zeile" ]; then
            #Open switch-backup2.sh with Parameters 
            #File to establish connection to each Switch and transfer Running Config 
            #to tftproot folder on local host
            date +"$2: %d.%m.%Y %H:%M"  >> mail.txt
            ./switch-backup2.sh $1 $2 $3 $4 $d
            sleep 1
      fi
done < ./switch.list

echo " " >> mail.txt
echo " " >> mail.txt
echo "Folgende Dateien wurden erstellt:" >> mail.txt
echo " " >> mail.txt

#List files in tftproot folder on local host and write it to mail.txt file
ls -ltr /var/lib/tftpboot/ >> mail.txt
echo " " >> mail.txt

#Mount Backup Folder on Samba-Share
mount -t cifs -o username=Sambauser,password=Sambapassword "//Path-To-Samba-Share" /BackupConfigs

#Check, if the mount point exists
file="/BackupConfigs/chkfile"

if [ -f "$file" ]
then
      #Delete all Configs older than 60 days (2 months)
      echo "Folgende Dateien älter als 2 Monate wurden gelöscht:" >> mail.txt
      find /BackupConfigs/*.cfg -mtime +60 -print -exec rm {} \; >> mail.txt
      #Move Configs
      mv /var/lib/tftpboot/*.cfg /BackupConfigs
      sleep 5
      umount /BackupConfigs
else
     figlet "ERROR" >> mail.txt
     echo "***** MOUNT-PUNKT NICHT ERREICHBAR - DATEIEN NICHT VERSCHOBEN ****" >> mail.txt
fi
date +"Endzeit: %d.%m.%Y %H:%M"  >> mail.txt

#Send Email
mail -s "Mail-Subject" "mailadress@mailserver.com" < mail.txt

switch-backup2.sh:

#!/usr/bin/expect

#Set Variables
set var_IP [lindex $argv 0]
set var_Name [lindex $argv 1]
set var_User [lindex $argv 2]
set var_Pass [lindex $argv 3]
set var_Datum [lindex $argv 4]

#Wait 5 seconds after every command
set timeout 5

#Open SSH connection for User to IP of the Switch
spawn /usr/bin/ssh $var_User@$var_IP

#Wait for message (yes/no) and sends ‚yes‘
expect "(yes/no)? " {
   send "yes\r"
}

#Wait for request of ‘password’ and send the password
expect "password:"
send "$var_Pass\r"

expect "Press any key"
send " "

expect "$"
send "config\r"

send "copy running-config tftp IPAdress-of-Linux-System $var_Datum-$var_Name.cfg\r"
expect "$"

send "exit\rexit\rexit\r"

expect "(y/n)"
send "y\n"

switch.list:

#IP-Adress,Name-Of-The-Switch,User,Password
IP-Adress-HP-Switch1,HP-Switch1,User,Password
IP-Adress-HP-Switch2,HP-Switch2,User,Password

Die Mail, die man erhält, sieht wie folgt aus:

Startzeit: 24.03.2017 14:31
  
 Zugriff auf folgende Switche:
 HP-Switch1: 24.03.2017 14:31
 HP-Switch2: 24.03.2017 14:31
 
  
 Folgende Dateien wurden erstellt:
  
 insgesamt 36
 -rw-rw-rw- 1 nobody nobody 14854 24. Mär 14:31 24-03-2017-HP-Switch1.cfg
 -rw-rw-rw- 1 nobody nobody  2216 24. Mär 14:31 24-03-2017-HP-Switch2.cfg

  
 Folgende Dateien älter als 2 Monate wurden gelöscht:
 /BackupConfigs/16-01-2017-HP-Switch1.cfg
 /BackupConfigs/16-01-2017-HP-Switch2.cfg
 
 Endzeit: 24.03.2017 14:33

Für eine zeitgesteuerten Ablauf muss man jetzt nur noch die crontab anpassen:

0 23 12 * * /Path-To-Script/backup.sh >> /Path-To-Logfiles/log.txt 2>&1

Dieses Script wird nun jeden 12. im Monat um 23:00 ausgeführt und schreibt zusätzlich die Ausgabe in ein Log-Datei namens log.txt

Share

  • -

Speedport-Hybrid mit OpenVPN

Kategorie : News

Viele Leute haben Geschwindigkeitsprobleme bei der Dateiübertragung zwischen zwei Sites über eine OpenVPN Verbindung, wenn die Speedport-Hybrid-Technologie der Deutschen Telekom an einem der Standorte verwendet wird.

Wenn der Verbindungsaufbau klappt und alles richtig eingestellt scheint, stellt man fest, dass beim Umschalten auf LTE bei hoher Last die Bandbreite für die Übertragung abfällt oder der Upload ggf. sogar ganz abbricht.

Aus eigener Erfahrung stellte ich irgendwann fest, dass die Einstellungen richtig sind. Das Problem schien jedoch die MTU (Maximum Transmission Unit, maximale Größe eines unfragmentierten Datenpakets in einem Computernetzwerk) zu sein.

Durch Zufall habe ich bei Google einen interessanten Eintrag gefunden, wo jemand das Problem hatte, dass er beim Öffnen einer Internetseite immer einen Fehler bekommen hat und den MTU-Wert mal auf 1280 stellen sollte. Danach war das Upload-Problem behoben.

Der zu niedrige MTU-Wert der DSL-Leitung ist also die Ursache für die Geschwindigkeitsprobleme.

In einem LAN wird in der Regel über Ethernet-Frames kommuniziert. Ein Ethernet-Frame hat eine maximale Größe von 1518 Byte (wenn alle Geräte des Layer2 Jumbo-Frames unterstützen, kann ein Ethernet-Frame eine Größe von 9038 Byte annehmen). Davon beansprucht der Header 14 Byte und die Prüfsumme (Frame Check Sequence, FCS) weitere 4 Byte. Somit verbleiben genau 1500 Byte für Nutzdaten. Die MTU für Ethernet beträgt also 1500 Byte. Bei DSL (PPPoE, Point-to-Point Protocol Over Ethernet) liegt der Wert bei < 1492.

Das führt dazu, dass die Pakete ausgepackt und in kleinere Pakete neu verpackt werden müssen.

Ist im Paket nun ein „don’t fragment (DF) bit“ gesetzt worden (z.B. von der Software), darf das Paket nicht fragmentiert werden. Dies kann dazu führen, dass eine Kommunikation nur langsam oder gar nicht zu Stande kommt.

Das gilt auch für VPN-Verbindungen und führte in diesem speziellen Fall zum Abbruch der Kommunikation.

Das LTE-Netz lässt nur einen MTU-Wert von um die 1300 zu, was dann beim Umschwenken der Kommunikation wegen erhöhtem Bandbreitenbedarf auf die LTE Leitung problematisch werden kann.

Nach einigen Versuchen mit dem Ping-Befehl und der Angabe verschiedener MTU-Paketgrößen bin ich irgendwann auf den Wert 1280 gekommen, der bei mir als letzter erfolgreicher Ping durchgegangen ist:

ping -l 1280 -f phi.de (1280 ist die MTU)

Damit ist für meine Internet-Leitung der optimale MTU-Wert 1280 Byte, wenn ich Problemen durch Fragmentierung beim automatischen Schwenk auf die LTE-Leitung vorbeugen will.

Das ist in meinem Fall der maximale Wert, bei dem noch ein Ping erfolgreich ist. Bei einer MTU-Größe von 1281 wird der Ping dann als nicht erfolgreich beendet.

Mit dem Wert wird die VPN-Verbindung jetzt sauber aufgebaut, und der Upload- und Downloadwert kommt zu 80% an die richtige DSL-Geschwindigkeit heran.

Share

  • -

Firefox 52 sperrt Plugins aus

Kategorie : News

Mozilla hat mit der Version 52 des Firefox Browsers nun die Ankündigung, Plug-Ins die die NPAPI Schnittstelle Verwenden nicht mehr zu unterstützen, wahrgemacht.

Dies betrifft auch die allseits beliebten Plug-Ins für Java und Flash was aktuell vermehrt zu Problemen führt, da viele Web Applikationen, ob der marktreife diverser Alternativen, immer noch auf diese veralteten Plug-Ins aufbauen.

Es gibt allerdings momentan noch einen Workaround die deaktivierten Plug-Ins wieder zu aktivieren, diese Möglichkeit soll aber mit dem nächsten Release auch abgeschaltet werden, den Herstellern der betroffenen Anwendungen bleibt aktuell also nur die veralteten Techniken endlich ein zu Motten und auf aktuelle Standards zu setzen.

Das ist allerdings immer leichter gesagt als getan, Beispielsweise habe ich mehrere Fibre Channel Switche in Betrieb deren Management ausschließlich über eine Java Anwendung erfolgen kann, hier bleibt dann aktuell nur der Internet Explorer oder die Erstellung einer „Management VM“ auf den älteren Versionen der verwendeten Browser abgelegt werden, diese sollte man allerdings dann wirklich nur für den internen Gebrauch verwenden.

Nicht schön aber es muss ja weitergehen.

 

Workaround

Im Firefox gibt man in der URL Zeile dazu die Adresse about:config ein.

Firefox warnt dann, dass die Gewährleistung bei möglichen Schäden hier endet.

Dort klicken wir auf „Ich bin mir der Gefahr bewusst!“

Mit einem Rechtsklick neben die Werte und einem Linksklick auf „Neu -> Boolean“ legen wir einen neuen Boolean Wert an, dieser kann nur die Werte „True“ und „False“ annehmen.

Der Name des boolean-Wertes lautet dann plugin.load_flash_only

Nach einem klick auf OK geben wir hier noch den Wert „false“ an und klicken erneut auf OK.

Nach einem Neustart des Browsers sollten alle vorher aktivierten Plugins wieder unter Add-ons > Erweiterungen angezeigt werden.

 

 

Share

  • -

Datenschutz Zertifizierung bei der phi

Seit April 2016 ist die phi Medien Systeme GmbH sicherheitszertifiziert nach der ISO/IEC-Norm 27001. Das bedeutet für Sie die Garantie höchster Sicherheitsstandards hinsichtlich der Vertraulichkeit, Integrität und Verfügbarkeit Ihrer Daten und Systeme – regelmäßig überprüft von den Sicherheitsexperten des TÜV Rheinland. Damit ist die Sicherheit der Daten und Systeme unserer Kunden integraler Bestandteil all unserer Geschäftsprozesse.

Prüfkriterien und Sicherheitsziele der TÜV Zertifizierung.

TÜV Zertifizierung 27001

Bei der ISO-27001-Zertifizierung durch den TÜV Rheinland wurden unter anderem folgende Bereiche der phi Medien Systeme GmbH untersucht und bewertet:

  • Sicherheitsrichtlinien
  • Organisation der Informationssicherheit
  • Personalsicherheit
  • Physische und umgebungsbezogene Sicherheit
  • Management der Kommunikation und des Betriebes
  • Zugangs- und Zugriffskontrolle
  • Management von Sicherheitsvorfällen
  • Erfüllung rechtlicher und organisatorischer Anforderungen
  • Business Continuity Management

Um diese Sicherheitsziele zu erreichen, hat die phi Medien Systeme GmbH ein Informations-Sicherheits-Management-System (ISMS) nach den Anforderungen der ISO/IEC 27001:2013 etabliert, welches die Grundlage für die Gewährleistung höchstmöglicher Sicherheit der Infrastrukturen für die Kunden der phi Medien Systeme GmbH darstellt, zusammen mit allen zugehörigen Informationen hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit. Die Normenkonformität und Funktionsfähigkeit des Sicherheitsmanagementsystems der phi Medien Systeme GmbH wurde vom unabhängigen Audit-Team überprüft und wird durch die Zertifizierung nach ISO 27001 bescheinigt.

Um unseren Kunden einen dauerhaften und gleichbleibend hohen Sicherheits-Standard zu garantieren, wird die Wirksamkeit des ISMS durch jährliche Überwachungsaudits sowie Re-Zertifizierung nach jeweils drei Jahren kontinuierlich überwacht und dokumentiert.

Share

Share