KDE4 Lock Screen Background anpassen

Hallo,

wenn ihr unter KDE4 den Standard Screen-Locker eingestellt habt, könnt ihr dort auch ein eigenes Hintergrundbild verwenden.

KDE Plasma < 5.5

Dazu müsst ihr als erstes eurer Image in den entsprechenden Pfad kopieren.

cp Pictures/xxx.jpg /usr/share/kde4/apps/ksmserver/screenlocker/org.kde.passworddialog/contents/ui/

Danach öffnet ihr die Datei main.qml mit eurem favorisierten Editor

und geht zur Image {-Sektion

Dort tauscht ihr die Zeile

source: theme.wallpaperPathForSize(parent.width, parent.height)

durch den Pfad zu eurem Image.

source: xxx.jpg

KDE Plasma 5.5

Bei KDE-Plasma 5.5 funktioniert leider der oben genannten Mechanismus NICHT mehr…

Dort wird einfach folgender Befehl ausgeführt:

kcmshell5 screenlocker

Dort kann man über das Menü ein Bild auswählen.

LSI-Raid Controller Megacli Kommandos

Hallo,

einige meiner Server, die ich betreue, haben LSI-RAID-Controller verbaut. Bei den LSI-Controllern gibt es die Möglichkeit über Linux diese komplett zu Konfigurieren und Abzufragen.
Leider ist das Megacli-Kommando extrem umfangreich und auch sehr unübersichtlich. Daher wollte ich einfach mal ein paar nützliche Kommandos mit euch teilen.

Übersicht der konfigurieren Virtual-Drives und Status

`which megacli` -LDInfo -Lall -aALL

Output:
Virtual Drive: 0 (Target Id: 0)
Name :
RAID Level : Primary-6, Secondary-0, RAID Level Qualifier-3
Size : 9.093 TB
Sector Size : 512
Is VD emulated : No
Parity Size : 3.637 TB
State : Optimal
Strip Size : 256 KB
Number Of Drives : 7
Span Depth : 1
Default Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disk's Default
Encryption Type : None
PI type: No PI

Is VD Cached: No

Status aller Festplatten mit den Werten Größe, Backplane, Slot, Firmware Status und Temperatur

`which megacli` -PDList -a0 | grep -e '^Coerced Size:' -e '^Enclosure Device ID:' -e '^Slot Number:' -e '^Firmware state:' -e '^Drive Temperature :'

Output:
Enclosure Device ID: 19
Slot Number: 0
Coerced Size: 1.818 TB [0xe8d00000 Sectors]
Firmware state: Online, Spun Up
Drive Temperature :39C (102.20 F)

Dann hatte ich das Problem, dass ich eine Festplatte getauscht habe, dabei die Global Spare eingesprungen ist und dadurch der Controller angefangen hat zu beepen.
Auch nach dem Rebuild blieb der Alarm. Per megacli kann man diesen auch stumm stellen.

megacli -AdpSetProp -AlarmSilence -aALL

Adapter 0: Set alarm to Silenced success.

Exit Code: 0x00

Man kann auch den Alarm permanent abschalten. Dazu folgendes Kommando:

megacli -AdpSetProp -AlarmDsbl -aALL

Mit folgendem Kommando kann man den Alarm wieder anschalten:

megacli -AdpSetProp -AlarmEnbl -aALL

WordPress XMLRPC Angriff

Hallo,

diesmal etwas in eigener Sache. Und zwar war mein Blog in letzter Zeit öfters down und ich habe mich gefragt, was da los ist.Der Server ging irgendwann in die Knie und warf beim Laden der Seite eine 502 – Bad Gateway Fehler.

Analyse des Angriffs

Im Log des Webservers tauchen folgende Meldungen auf:


/var/log/nginx/access.log

xx.xxx.xx.xxx - - [22/Jan/2015:03:36:59 +0100] "POST /xmlrpc.php HTTP/1.0" 403 529 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
xx.xxx.xx.xxx - - [22/Jan/2015:02:57:50 +0100] "POST /wp-login.php HTTP/1.1" 200 1326 "http://warpdrive-on.de/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0"

Nach kurzer google-Recherche stellte sich heraus, dass es in den letzten WordPress Versionen eine Sicherheitslücke gibt, und zwar die xmlrpc-Schnittstelle. Darüber können Blogeinträge über externe Programme hinzugefügt werden.

Schließen der Sicherhheitslücke

Da ich diese Möglichkeit sowieso nicht benutze, entschied ich, den Zugriff auf die Datei xmlrpc.php direkt im Webserver zu sperren.

Dies kann im nginx-Webserver in der virtual Host-Konfiguration mit folgendem Eintrag eingestellt werden:


/etc/nginx/sites-enabled/default

location /xmlrpc.php {
deny all;
}

Bot-Zugriffe mit fail2ban blockieren

Damit war das Problem erst einmal behoben. Da ich aber trotzdem noch zahlreiche Seitenaufrufe hatte (die Zahlen hatten nichts mit der Realität zu tun 🙂 ), dachte ich mir, wenn ich grad dabei bin sperre ich diese vermeindlichen Bots auch noch aus. Dazu gibt es die Möglichkeit, diese mit der Software Fail2ban zu blocken.

Als erstes legt man idealerweise im Nginx conf.d Verzeichnis eine Datei bots.map an.


/etc/nginx/conf.d/bots.map

map $http_user_agent $is_bot {
default 0;

~Sogou 1;
~Abonti 1;
~Pixray 1;
~Python 1;
~Spinn3r 1;
~libwww-perl 1;
~Wget 1;
~Curl 1;
~Ezooms 1;
~mShots 1;
~SemrushBot 1;
~Exabot 1;
~ZmEu 1;
~iCjobs 1;
~QuerySeekerSpider 1;
~Baiduspider 1;
~AhrefsBot 1;
~CareerBot 1;
~coccoc 1;
~MJ12bot 1;
~SeznamBot 1;
~spbot 1;
~ShowyouBot 1;
~adressendeutschland 1;
~PagesInventory 1;
~aboutWebSearch 1;
~Java 1;
~JCE 1;
~bitlybot 1;
~WeSEE 1;
~updown_tester 1;
~200PleaseBot 1;
~Nutch 1;
~HTTP_Request 1;
~AnyOther 1;
~Crawler 1;
~BLEXBot 1;
~yacybot 1;
~Cliqzbot 1;
}

Durch das Nginx-Module map wird entschieden, ob ein spezifizierter User-Agent als Bot definiert wird (die Variable $is_bot also als Wert 1 enthält) oder nicht.

Anschließend bindet man man die Datei als Include in die Nginx.conf ein:


/etc/nginx/nginx.conf

http {

include /etc/nginx/conf.d/bots.map;

}

Dann wird noch in der vhost konfiguration abgefragt, ob die is_bot Variable gesetzt ist und wenn ja, wird der Zugriff gesperrt.


/etc/nginx/sites-enabled/default

server {
...

if ( $is_bot ) {
return 444;

}

}

Um hier eine dauerhafte Lösung zu schaffen, sollten bereits abgewiesene Bots dauerhaft gesperrt werden. Dazu wird in Fail2ban eine Ressource angelegt, die das Access-Log des Webservers überwacht und schaut, ob der Statuscode 444 auftaucht. Diese IP-Adressen würden dann blockiert werden.

Zuerst legt man also eine neue Filter-Regel an. Im Verzeichnis /etc/fail2ban/filter.d/ eine Datei nginx-bots.conf angelegt.


/etc/fail2ban/filter.d/nginx-bots.conf

# Fail2Ban configuration file
#
# List of bad requests
#
# Server: Nginx
# Author: Sergej Müller
#

[Definition]

# Option: failregex
# Notes : Detection of 444 requests.
# Values: TEXT
#

failregex = ^ - .+ 444 0 ".+"$

# Option: ignoreregex
# Notes : Regex to ignore.
# Values: TEXT
#

ignoreregex =

Damit die Filterregel auch geladen wird, muss folgendes in der Datei /etc/fail2ban/jail.conf angehängt werden:


/etc/fail2ban/jail.conf

[nginx-bots]

enabled = true
port = http
filter = nginx-bots
logpath = /var/log/nginx/access.log
maxretry = 0
findtime = 86400
bantime = -1


Anschließend sowohl nginx als auch Fail2ban durchstarten und der Anti-Bot-Schutz ist aktiv.

Thinkpad T420 Boot Freeze

Letztens mal Linux Mint installiert und dabei festgestellt, dass mein Laptop beim Systemstart ab und an hängen bleibt.

Im syslog war zu sehen, dass er beim starten von udev stehen bleibt.
Bisschen gegoogelt und manche User meinten, dass das eine ACPI bzw Power-Management-Geschichte sein könnte.

Abhilfe würde ein Kernel-Paramenter namens „nox2apic“ schaffen. Den Paramenter trägt man unter /etc/default/grub ein und bringt grub mit update-grub auf den neuesten Stand.

Weiterhin hatte ich noch einen Freeze wenn ich die Displayhelligkeit über die Funktionstasten regeln wollte. Dazu habe ich unter /usr/share/X11/xorg.conf.d eine Datei erstellt (ich habe sie 12-Brightness.conf genannt, ist aber latte).

Dort trägt man folgendes ein:

Section "Device"
Identifier "Default Device"
Option "RegistryDwords" "EnableBrightnessControl=1"
EndSection

Hinzufügen eines custom-Repositorys in Novell SMT

Hi,

im Novell SMT hat man die Möglichkeit, externe Repositorys anzubinden, die dann genauso gemirrort werden, wie die Repos von Novell selbst auch (zb. SLES 11).
Man muss sich aber vorher im klaren sein, an welche Produkte man das Repo anhängen möchte.

Konkret war es bei uns so, dass wir beim Registrieren der Sles11-Server am SMT ein Repo mit ausrollen wollten, was zb die VMware-Tools enthält.

Zuerst sucht man sich die Produkt-ID des Produkts heraus, mit dem man das Repository ausrollen möchte (z.b Sles11-SP3-x86_64):

smt-list-products

Dann bekommt man eine u.U recht lange Liste an Produkten, in der man sich die ID heraussuchen muss. Sieht dann zb so aus:

| 3890 | SUSE_SLES | 11.3 | x86_64 | – | 5 |

Nun kann man das Repo unter Angabe der URL und ID hinzufügen:

smt-setup-custom-repos –productid 3890 –name ‚Blablubb-Repo‘ –exturl ‚http://blablubb.org‘

Das Repository wird dann beim Registrieren eines SLES11-Sp3-Clients mit hinzugefügt.

Targetcli Skript

Hi,

wenn man einen Standard-Linux-Server zur Bereitstellung von Speicher per Fibre-Channel nutzen möchte, kann man das Tool Targetcli benutzen.
Ich habe ein Skript zum Konfigurieren eines Fibre-Channel Targets auf einem Linux Host geschrieben.
Nachdem das Target angelegt ist, soll eine Lun angelegt werden und die entsprechend gezonten Server Zugriff erhalten.

Hinweis: Hier wird ein Qlogic 2562 HBA verwendet. Dieser funktioniert mit targetcli sehr gut.

addfclun.sh

#!/bin/bash
port1=`targetcli „/qla2xxx/ info“ |awk ‚/Allowed WWNs list/‘ |cut -d‘:‘ -f2 |awk -F‘,‘ ‚{print $1}’|cut -c2-21`
port2=`targetcli „/qla2xxx/ info“ |awk ‚/Allowed WWNs list/‘ |cut -d‘:‘ -f2 |awk -F‘,‘ ‚{print $2}’|cut -c2-21`

function createtarget {
targetcli /qla2xxx create $port1
targetcli /qla2xxx create $port2
}
function createlun {
read -p „Bitte den Namen der Lun angeben: “ lunname
ls /dev/mapper
read -p „Bitte Logical-Volume angeben (voller Pfad): “ lv
targetcli /backstores/block create $lunname $lv
targetcli /qla2xxx/$port1/luns create /backstores/block/$lunname
targetcli /qla2xxx/$port2/luns create /backstores/block/$lunname
}
function maplun {
read -p „Bitte die WWN des ersten Ports des anzubindenden Servers angeben: “ wwn1
targetcli /qla2xxx/$port1/acls create $wwn1
read -p „Bitte die WWN des zweiten Ports des anzubindenden Servers angeben: “ wwn2
targetcli /qla2xxx/$port2/acls create $wwn2
}

PS3=“Auswahl: “
echo „Was moechten sie tun: “
select aufgabe in „Target anlegen“ „Lun anlegen“ „Lun mappen“ „beenden“;
do
case $aufgabe in
„Target anlegen“) createtarget;;
„Lun anlegen“) createlun ;;
„Lun mappen“) maplun ;;
„beenden“) break;;
esac
done

KVM Virtual Machines made easy

Linux-KVM

Basis-Konfiguration von KVM-VMs (ohne Netzwerk):

Festplatte erstellen:
qemu-img create -f qcow2 vmhdd.qcow2 8G

System installieren:
qemu-system-x86_64 –enable-kvm -cdrom Downloads/SLES-11-SP2-DVD-x86_64-GM-DVD1.iso -vga vmware -m 3000 -smp 2 -boot d vmhdd.qcow2

System mit Netzwerk installieren:
qemu-system-x86_64 –enable-kvm -cdrom ~/Downloads/de_windows_7_professional_x64_dvd_X15-65813.iso -vga vmware -m 3000 -smp 2 -net nic,macaddr=`printf ‚DE:AD:BE:EF:%02X:%02X\n‘ $((RANDOM%256)) $((RANDOM%256))` -net bridge,br=br1 -boot c /data/VMs/testvm.qcow2

VM starten:
qemu-system-x86_64 -enable-kvm -vga vmware -m 3000 -smp 2 LMDE.qcow2

Filesystem-Backups mit xfsdump

Hi,

XFS-Filesysteme haben den großen Vorteil, dass sie per Dump im laufenden Betrieb komplett weggeschrieben werden können.
Es empfiehlt sich, vorab einen ssh-key auf dem Zielsystem liegen zu haben.

Hier als Beispiel der Dump vom kompletten Filesystem und anschließender Komprimierung und Ablage per ssh auf einem Zielsystem.

xfsdump -l0 – / | gzip -c | ssh user@host dd of=/somewhere/backup.dgz

Alternativ über ein Dump File auf ein gemountetes Volume:

xfsdump -J -v trace -f /mnt/backup/hosts_root /

Der Dump kann auch wieder zurückgespielt werden. In dem Fall würde man dann den Server mit einer Live-CD booten, die Partitionen mounten und das Image zurückschreiben.

ssh user@host „dd if=/somewhere/backup.dgz“ | gunzip -c | xfsrestore – /

Alternativ über das dump-File von einem gemounteten Volume:

xfsrestore -v trace -f /mnt/backup/hosts_root /

Ubuntu Firewall Skript

Hey,

hier n kleines Skript zur bequemeren Konfiguration von iptables unter Ubuntu.

Hier das Konfigurationsskript:

/etc/iptables.sh

#!/bin/sh

# Iptables
FW=“/sbin/iptables“

# vorhandene Regeln & Ketten löschen
$FW -F
$FW -X
$FW -t nat -F

# Standardregeln
$FW -P INPUT ACCEPT
$FW -P FORWARD ACCEPT
$FW -P OUTPUT ACCEPT

$FW -A INPUT -p tcp –dport www -s xxx.xx.xx.x/16 -j ACCEPT
$FW -A INPUT -p tcp –dport www -j DROP
$FW -A INPUT -p tcp –dport https -s xxx.xx.xx.x/16 -j ACCEPT
$FW -A INPUT -p tcp –dport https -j DROP

$FW -A INPUT -p tcp –dport ssh -s xxx.xx.xx.xxx -j ACCEPT
$FW -A INPUT -p tcp –dport ssh -s xxx.xx.xx.xxx -j ACCEPT
$FW -A INPUT -p tcp –dport ssh -s xxx.xx.xx.xxx -j ACCEPT
$FW -A INPUT -p tcp –dport ssh -s xxx.xx.xx.xxx -j ACCEPT
$FW -A INPUT -p tcp –dport ssh -s xxx.xx.xx.xxx -j ACCEPT
$FW -A INPUT -p tcp –dport ssh -s xxx.xx.xx.xxx -j ACCEPT
$FW -A INPUT -p tcp –dport ssh -j DROP

$FW -A INPUT -p tcp –dport 21 -s xxx.xx.xx.xxx -j ACCEPT
$FW -A INPUT -p tcp –dport 21 -j DROP

$FW -A INPUT -p tcp –dport 7777 -s xxx.xx.xx.xxx -j ACCEPT
$FW -A INPUT -p tcp –dport 7777 -j DROP

Hier das Init-Skript:

/etc/init.d/firewall

#!/bin/sh
### BEGIN INIT INFO
# Provides: iptables
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Should-Start: $syslog
# Should-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start or stop the firewall daemon.
### END INIT INFO

. /lib/lsb/init-functions

case „$1“ in
start)
/etc/iptables.sh
iptables -L
;;
stop)
iptables -F
iptables -X
iptables -L
;;
status)
iptables -L
;;
*)
echo „Usage: /etc/init.d/firewall {start|stop|status}“
exit 1
;;
esac

exit 0

Automatisches Laden des Skripts in den Default-Runlevels:

update-rc.d firewall defaults

Cisco Nexus 5k with Cisco UCS scripted FC-Zoning configuration

Infrastruktur

Seit ca einem Jahr haben wir im Datacenter-Bereich eine homogene Cisco-Infrastruktur. Im Rahmen eines Projektes sind Cisco UCS Systeme zusammen mit Cisco Nexus 5k Datacenter Switches beschafft worden.
Wir haben an zwei Standorten jeweiles zwei Nexus-Switches, an dem pro Seite jeweils ein Storage-System angeschlossen ist.
Zusätzlich haben wir an beiden Standorten Cisco-Ucs-Systeme aufgebaut.
Wir haben uns nun überlegt, wie wir unsere Server (und Blades) an die Nexus-Infrastruktur anbinden und haben uns dann für Fibre-Channel entschieden.
Dann stellte sich die Frage, wie man dann das Zoning über die Nexus-Switches löst. Klar ist, diese Aufgabe müssen wir Serveradmins übernehmen. Nachdem wir uns den Cisco Prime Datacenter Network Manager angeschaut hatten (Gui Lösung zum Managen von unter anderem auch Nexus-Switches) war uns klar, dass wir das lieber über die Konsole per Script machen wollen.
Natürlich ist bei vielen die Infrastruktur unterschiedlich und wir haben es bei uns auch bewusst relativ einfach gehalten.
Es wird also nur in einer Fabric ein Port des Storages auf einen Port des Servers gezont.

Skriptaufbau

Wir haben auf einem zentralen Linux-Server ein Skript gebaut, welches einen bestendenden Storage mit einem Server verbindet.
Was soll das Skript nun genau tun?
Das Skript soll sich zu den Fabric-Interconnects verbinden, sich von dort die Service-Profile holen und diese in einem Auswahlmenü präsentieren.
Dann soll die WWPN der vHBAs des ausgewählten Service-Profils besorgt werden und in ein Array geladen werden.
Schließlich soll der Device-Alias angelegt, die Zone gebaut und zum Zoneset hinzugefügt werden. Nach einer Sichtprüfung soll abgefragt werden ob die Zone jetzt aktiviert werden soll.
Das wars im Prinzip schon. Die eigentliche Konfiguration der Nexus-Switches wird per Shell-Funktion vorgenommen.
Hier das Skript.

Code

#!/bin/bash
#
# Funktion zum Überprüfen ob ein (der Funktion mitgegebenes) Element im Array der Service-Profiles von FI-E12 existiert
function exists() {
element=${1}
for i in ${arraye12[@]}; do
if [ $i == $element ]; then
echo „1“
fi
done
return 0
}
# Wegschreiben der Daten in einen Ordner, der nach dem aktuellen Datum + Uhrzeit benannt ist
DATE=`date +%d%m%y-%H%M`
mkdir -p /home/vi-admin/Backup/Zoning/$DATE
FOLDER=/home/vi-admin/Backup/Zoning/$DATE
#
# Fest definierter Storage, mit dem gezont werden soll. Achtung: Diese Namen müssen als Device-Alias im jeweiligen Nexus existieren.
STORAGE1=“VSTORE1″
STORAGE2=“VSTORE2″
# Funktion zum Erstellen der Zone auf NX1
function createzonenx1 {
echo „conf t“ > createzonenx1_$ziel.txt
echo „zone name $ziel“_Port1″ vsan 1234“ >> createzonenx1_$ziel.txt
echo „member device-alias $STORAGE1″_Port1″“ >> createzonenx1_$ziel.txt
echo „member device-alias $ziel“_Port1″“ >> createzonenx1_$ziel.txt
echo „sh zone“ >> createzonenx1_$ziel.txt
ssh fczoning@nexus1 < createzonenx1_$ziel.txt mv createzonenx1_$ziel.txt $FOLDER/ } # Funktion zum Erstellen der Zone auf NX2 function createzonenx2 { echo "conf t" > createzonenx2_$ziel.txt
echo „zone name $ziel“_Port2″ vsan 4321“ >> createzonenx2_$ziel.txt
echo „member device-alias $STORAGE1″_Port2″“ >> createzonenx2_$ziel.txt
echo „member device-alias $ziel“_Port2″“ >> createzonenx2_$ziel.txt
echo „sh zone“ >> createzonenx2_$ziel.txt
ssh fczoning@nexus2 < createzonenx2_$ziel.txt mv createzonenx2_$ziel.txt $FOLDER/ } # Funktion zum Erstellen der Zone auf NX3 function createzonenx3 { echo "conf t" > createzonenx3_$ziel.txt
echo „zone name $ziel“_Port1″ vsan 1234“ >> createzonenx3_$ziel.txt
echo „member device-alias $STORAGE2″_Port1″“ >> createzonenx3_$ziel.txt
echo „member device-alias $ziel“_Port1″“ >> createzonenx3_$ziel.txt
echo „sh zone“ >> createzonenx3_$ziel.txt
ssh fczoning@nexus3 < createzonenx3_$ziel.txt mv createzonenx3_$ziel.txt $FOLDER/ } # Funktion zum Erstellen der Zone auf NX4 function createzonenx4 { echo "conf t" > createzonenx4_$ziel.txt
echo „zone name $ziel“_Port2″ vsan 4321“ >> createzonenx4_$ziel.txt
echo „member device-alias $STORAGE2″_Port2″“ >> createzonenx4_$ziel.txt
echo „member device-alias $ziel“_Port2″“ >> createzonenx4_$ziel.txt
echo „sh zone“ >> createzonenx4_$ziel.txt
ssh fczoning@nexus4 < createzonenx4_$ziel.txt mv createzonenx4_$ziel.txt $FOLDER/ } # Funktion zum Hinzufügen der Zone zum Zoneset auf NX1 function addzonesetnx1 { echo "conf t" > addzonesetnx1_$ziel.txt
echo „zoneset name FABRICA_UCS1 vsan 1234“ >> addzonesetnx1_$ziel.txt
echo „member $ziel“_Port1″“ >> addzonesetnx1_$ziel.txt
echo „sh zoneset“ >> addzonesetnx1_$ziel.txt
ssh fczoning@nexus1 < addzonesetnx1_$ziel.txt mv addzonesetnx1_$ziel.txt $FOLDER/ } # Funktion zum Hinzufügen der Zone zum Zoneset auf NX2 function addzonesetnx2 { echo "conf t" > addzonesetnx2_$ziel.txt
echo „zoneset name FABRICB_UCS1 vsan 4321“ >> addzonesetnx2_$ziel.txt
echo „member $ziel“_Port2″“ >> addzonesetnx2_$ziel.txt
echo „sh zoneset“ >> addzonesetnx2_$ziel.txt
ssh fczoning@nexus2 < addzonesetnx2_$ziel.txt mv addzonesetnx2_$ziel.txt $FOLDER/ } # Funktion zum Hinzufügen der Zone zum Zoneset auf NX3 function addzonesetnx3 { echo "conf t" > addzonesetnx3_$ziel.txt
echo „zoneset name FABRICA_UCS1 vsan 1234“ >> addzonesetnx3_$ziel.txt
echo „member $ziel“_Port1″“ >> addzonesetnx3_$ziel.txt
echo „sh zoneset“ >> addzonesetnx3_$ziel.txt
ssh fczoning@nexus3 < addzonesetnx3_$ziel.txt mv addzonesetnx3_$ziel.txt $FOLDER/ } # Funktion zum Hinzufügen der Zone zum Zoneset auf NX4 function addzonesetnx4 { echo "conf t" > addzonesetnx4_$ziel.txt
echo „zoneset name FABRICB_UCS1 vsan 4321“ >> addzonesetnx4_$ziel.txt
echo „member $ziel“_Port2″“ >> addzonesetnx4_$ziel.txt
echo „sh zoneset“ >> addzonesetnx4_$ziel.txt
ssh fczoning@nexus4 < addzonesetnx4_$ziel.txt mv addzonesetnx4_$ziel.txt $FOLDER/ } # Funktion zum Erstellen des Device-Alias des Service-Profiles auf NX1 function createdevicealiasnx1 { echo "conf t" > createdevicealiasnx1_$ziel.txt
echo „device-alias database“ >> createdevicealiasnx1_$ziel.txt
echo „device-alias name $ziel“_Port1″ pwwn $i“ >> createdevicealiasnx1_$ziel.txt
echo „device-alias commit“ >> createdevicealiasnx1_$ziel.txt
echo „sh device-alias database“ >> createdevicealiasnx1_$ziel.txt
ssh fczoning@nexus1 < createdevicealiasnx1_$ziel.txt mv createdevicealiasnx1_$ziel.txt $FOLDER/ } # Funktion zum Erstellen des Device-Alias des Service-Profiles auf NX2 function createdevicealiasnx2 { echo "conf t" > createdevicealiasnx2_$ziel.txt
echo „device-alias database“ >> createdevicealiasnx2_$ziel.txt
echo „device-alias name $ziel“_Port2″ pwwn $i“ >> createdevicealiasnx2_$ziel.txt
echo „device-alias commit“ >> createdevicealiasnx2_$ziel.txt
echo „sh device-alias database“ >> createdevicealiasnx2_$ziel.txt
ssh fczoning@nexus2 < createdevicealiasnx2_$ziel.txt mv createdevicealiasnx2_$ziel.txt $FOLDER/ } # Funktion zum Erstellen des Device-Alias des Service-Profiles auf NX3 function createdevicealiasnx3 { echo "conf t" > createdevicealiasnx3_$ziel.txt
echo „device-alias database“ >> createdevicealiasnx3_$ziel.txt
echo „device-alias name $ziel“_Port1″ pwwn $i“ >> createdevicealiasnx3_$ziel.txt
echo „device-alias commit“ >> createdevicealiasnx3_$ziel.txt
echo „sh device-alias database“ >> createdevicealiasnx3_$ziel.txt
ssh fczoning@nexus3 < createdevicealiasnx3_$ziel.txt mv createdevicealiasnx3_$ziel.txt $FOLDER/ } # Funktion zum Erstellen des Device-Alias des Service-Profiles auf NX4 function createdevicealiasnx4 { echo "conf t" > createdevicealiasnx4_$ziel.txt
echo „device-alias database“ >> createdevicealiasnx4_$ziel.txt
echo „device-alias name $ziel“_Port2″ pwwn $i“ >> createdevicealiasnx4_$ziel.txt
echo „device-alias commit“ >> createdevicealiasnx4_$ziel.txt
echo „sh device-alias database“ >> createdevicealiasnx4_$ziel.txt
ssh fczoning@nexus4 < createdevicealiasnx4_$ziel.txt mv createdevicealiasnx4_$ziel.txt $FOLDER/ } # Funktion zum Aktivieren des Zonesets auf NX1 function activatezonesetnx1 { echo "conf t" > activatezonesetnx1_$ziel.txt
echo „zoneset activate name FABRICA_UCS1 vsan 1234“ >> activatezonesetnx1_$ziel.txt
echo „wr“ >> activatezonesetnx1_$ziel.txt
ssh fczoning@nexus1 < activatezonesetnx1_$ziel.txt mv activatezonesetnx1_$ziel.txt $FOLDER/ } # Funktion zum Aktivieren des Zonesets auf NX2 function activatezonesetnx2 { echo "conf t" > activatezonesetnx2_$ziel.txt
echo „zoneset activate name FABRICB_UCS1 vsan 4321“ >> activatezonesetnx2_$ziel.txt
echo „wr“ >> activatezonesetnx2_$ziel.txt
ssh fczoning@nexus2 < activatezonesetnx2_$ziel.txt mv activatezonesetnx2_$ziel.txt $FOLDER/ } # Funktion zum Aktivieren des Zonesets auf NX3 function activatezonesetnx3 { echo "conf t" > activatezonesetnx3_$ziel.txt
echo „zoneset activate name FABRICA_UCS1 vsan 1234“ >> activatezonesetnx3_$ziel.txt
echo „wr“ >> activatezonesetnx3_$ziel.txt
ssh fczoning@nexus3 < activatezonesetnx3_$ziel.txt mv activatezonesetnx3_$ziel.txt $FOLDER/ } # Funktion zum Aktivieren des Zonesets auf NX4 function activatezonesetnx4 { echo "conf t" > activatezonesetnx4_$ziel.txt
echo „zoneset activate name FABRICB_UCS1 vsan 4321“ >> activatezonesetnx4_$ziel.txt
echo „wr“ >> activatezonesetnx4_$ziel.txt
ssh fczoning@nexus4 < activatezonesetnx4_$ziel.txt mv activatezonesetnx4_$ziel.txt $FOLDER/ } # Alle Service-Profiles von fi1 und fi2 laden und in jeweils ein Array laden arraye12=(`ssh fczoning@fi1 "scope org AAA;show service-profile" |awk {'print $1'} |egrep -v "(Service|-)"| cut -c5-`) arraye21=(`ssh fczoning@fi2 "scope org AAA;show service-profile" |awk {'print $1'} |egrep -v "(Service|-)"| cut -c5-`) # Per Menü ein Service-Profile auswählen PS3="Auswahl: " echo "Bitte das Service Profil auswählen: " select ziel in "${arraye12[@]}" "${arraye21[@]}" "beenden"; do if [ $ziel == "beenden" ]; then break fi echo $ziel # Wenn das gewählte Service-Profile in Arraye12 existiert, dann Methoden für fi1 bzw nx1 und nx2 ausführen if [ "$(exists $ziel)" == "1" ]; then arrhbae12=(`ssh fczoning@fi1 "scope org AAA;scope service-profile \$ziel;show vhba" | awk {'print $3'} | tr '[:upper:]' '[:lower:]' |egrep -v "(id|-)" | tail -n +3`) # 3. Element des Arrays abfragen -> Entspricht dem 3.HBA des Service-Profiles
for i in „${arrhbae12[2]}“
do
# Funktionsaufruf. Hier wird der jeweilige Nexus konfiguriert
createdevicealiasnx1
createzonenx1
addzonesetnx1

# Abfrage ob die Zone nun aktiviert werden soll. Mit den Ausgaben der jeweiligen Funktionen kann man überprüfen ob das alles so korrekt ist.
read -p „zoneset jetzt aktivieren? j n: “ activate
if [ $activate == „j“ ];
then
activatezonesetnx1
fi

done
for i in „${arrhbae12[3]}“
do
# Funktionsaufruf. Hier wird der jeweilige Nexus konfiguriert
createdevicealiasnx2
createzonenx2
addzonesetnx2

# Abfrage ob die Zone nun aktiviert werden soll. Mit den Ausgaben der jeweiligen Funktionen kann man überprüfen ob das alles so korrekt ist.
read -p „zoneset jetzt aktivieren? j n: “ activate
if [ $activate == „j“ ];
then
activatezonesetnx2
fi
done
exit 0
else
arrhbae21=(`ssh fczoning@fi2 „scope org AAA;scope service-profile \$ziel;show vhba“ | awk {‚print $3‘} | tr ‚[:upper:]‘ ‚[:lower:]‘ |egrep -v „(id|-)“ | tail -n +3`)
# 4. Element des Arrays abfragen -> Entspricht dem 3.HBA des Service-Profiles
for i in „${arrhbae21[2]}“
do
# Funktionsaufruf. Hier wird der jeweilige Nexus konfiguriert
createdevicealiasnx3
createzonenx3
addzonesetnx3

# Abfrage ob die Zone nun aktiviert werden soll. Mit den Ausgaben der jeweiligen Funktionen kann man überprüfen ob das alles so korrekt ist.
read -p „zoneset jetzt aktivieren? j n: “ activate
if [ $activate == „j“ ];
then
activatezonesetnx3
fi
done
for i in „${arrhbae21[3]}“
do
# Funktionsaufruf. Hier wird der jeweilige Nexus konfiguriert
createdevicealiasnx4
createzonenx4
addzonesetnx4

# Abfrage ob die Zone nun aktiviert werden soll. Mit den Ausgaben der jeweiligen Funktionen kann man überprüfen ob das alles so korrekt ist.
read -p „zoneset jetzt aktivieren? j n: “ activate
if [ $activate == „j“ ];
then
activatezonesetnx4
fi
done
fi
break
done

Technology and Geek