Kategorie-Archiv: Serveradministration

die neuen SAP Wartungsverträge sind im Zuge der einführung des SAP Active Global Support und dem SAP Solution Manager, der eng damit verbunden ist, gekommen. DAmals 2008 ging großes Raunen durch die Kundenkreise, da SAP mit Einführung des SAP Enterprise Support die Beiträge für den Support angehoben hat.Der SAP Active Global Support bedeutet hier sozusagen eine Menge von Reformen, die im SAP-Support durchgeführt wurden, um diesen für Kunden, die SAP-Unternehmenslösungen einsetzen, effektiver zu gestalten. Zu diesen REformen gehört auch der SAP solution Manager, der es einfacher machen soll, eine SAP-landschaft in allen ihren Phasen (einführung, Betrieb, Optimierung) zu verwalten und auf Probleme zu reagieren. Das Ziel von SAP Active Global support und SAP Solution Manager waren also, die Kosten bei der verwlatung und bei der Problemlösung von SAP-Landschaften für die Kunden zu senken.

Jeder SAP-Kunde, der SAP-Unternehmenslösungen verwenden will, sollte einen SAP Wartungsvertrag abschließen. dabei gibt es verschiedene Levels – je höher das Level des Vertrages, desto mehr Leistungen genießt auch der Kunde.

In jedem Wartungsvertrag gibt es unterschiedliche Service Level Agreements, in denen beispielsweise festgelegt wird, wie schnell der SAP Support auf Probleme reagieren muss und für welche Konfiguration oder Lösungen der Support überhaupt angeboten wird. Auch bestimmte SAP-Produkte wie der SAP Solution Manager können nur genutzt werden, wenn Wartungsverträge eines bestimmten LEvels abgeschlossen wurden. Je höher der Wartungsvertrag, desto mehr funktionen des Solution Managers kann man letztendlich auch nutzen.

Der Standardsupportvertrag kostet dem Kunden pro jahr 15% seiner Lizenzierungskosten für die von ihm georderten SAP-Produkte.

Die verschiedenen Wartungsverträge

SAP Enterprise Support

SAP enterprise support ist ein Premium rsupport Wartungsplan für SAP-Kunden, der wie der Name schon sagt an Großkonzerne gerichtet ist. Dieser Plan ist der am häufigsten anzutreffende Supportplan.

Im Enterprise Support Plan ist sichergestellt, dass die Kunden Zugriff auf die neusten technologien und Tool shaben und jederzeit mit SAP Experten in Kotnakt treten können.

Der SAP ENterprise Support geht darüber hinaus nur die SAP Applikationen zu supporten, sondern bietet einen Ende-zu-Ende Support für die gesamte Plattform des Kunden.

Dieser Wartungsvertrag glänzt auch durch eine sehr geringe Reaktionszeit des SAP-Supports. support-Requests der Priorität 1 werden innerhalb von einer Stunde bearbeitet, Requests der Priorität 2 innerhalb von 2 Stunden. Desweiteren wird bei Request der Priorität 1 nicht nur die Reaktiosnzeit an sich garantiert, sondern auch die Zeit für das Corrective Action Commitment, also letztendlch die Lösung, den Workaround etc. für ein Problem, innerhalb von 4 Stunden, garantiert.

In diesem Wartungsvertrag haben die Kunden desweiteren Zugriff auf die SAP Enterpries support Academy, welche eine Art Knowledge Management Plattform ist, in welchen Experten Wissen über kritische Prozeduren in SAP-Systemen sammeln und austauschen.

SAP ActiveEmbedded

SAP ActiveEmbedded ist noch höher angesiedelt als der Enterprise support und bietet zusätzlich zu den Lesitungen aus dem Enterprise Support zusätzliche Unterstützung bei der Optimierung von Lösungen und der beschleunigten Adaption von neuen Technologien.

SAP MaxAttention

Der MaxAttention Vertrag ist noch höher angesiedelt als der Enterprise Support und noch höher als ActiveEmbedded

SAP Standard-Support

dieser Vertrag enthält grundlegende Support- und Wartungsfunktionalitäten. Dieser bietet die minimalen Support-Serviecs die notwendig sind um die eingesetzten Syteme und Applikationen am laufen zu halten.

zu den ausgelieferten Leistungen gehören

Tools zur Sicherstellung der Robustheit der SAP-Applikationen, dazu gehören
- Fernzugriff (remote Access)
- SAP EalryWatch Alert
- SAP GoingLive Check
- SAP goingLive Upgrade
- SAP OS/DB Migration Check Service
Zugriff auf SAP Notes und den SAP Ervice Marketplace über das web
- dadurch Zugriff auf Tools wie beispielsweise den SAP Download Manager, den Software Provisioning Manager und andere sinnvolle tools der SAP Administration.
- automatisches einspielen von Fixes und Workarounds, die als SAP Note dokumentiert isnd, mit hilfe des SAP Note Assistant
SAP Solution Manager enterprise Edition, jedoch nicht im vollen Funktionsumfang
support Packages für die lizenzierten applikationen, die Fehler bereinigen oder verhindern sollen
Enhancement Packages zur Erweiterung des Funktionsumfangs der lizenzierten applikationen.
Technology Updates, welche die Zusamemnarbeit mit Betriebssystemen und Datenbanken verbessern sollen.
„Global Incident Handling“ durch den SAP Support. Praktisch eine Art Hotline, die auf Anfragen betreffend Standard Suport-Lösungen reagiert. Wird 24/7 betrieben. Als sprache ist englisch vorgeschrieben.

SAP standard Support For Large Enterprises

Dieser steht leicht über dem Standard Support Vertrag. Die wesentlcihste Änderung ist die, dass dies der niedrigste Wartungsvertrag ist, der die volle nutzung aller Solution-Manager-funktionen erlaubt.

Advanced Secure Support

Dieser Vertrag ist sozusagen der Standard Support Service erweitert um einige Sicherheitsoptionen. Dieser Wartungsvertrag wird oft abgeshclossen bei SAP-Kunden, die in den Bereichen Verteidigung/Militär, Bankgeschäfte, Versicherungsgeschäfte, High-Tech-ijndustrie oder als öffentliches Institut und Behörde auftreten.

Man kann diese Sicherheitszusätze auch auf den Enterprise Support-Wartungsvertrag „hinzubuchen“. Der Wartungsvertrag nennt sich dann SEPT Enterprise Support, Advacned Security Edition.

Die zusätzlichen Sicherheitsleistungen werden in sogenannten Advanced SEcure Support Service Packages geliefert und sollen der Sicherheit der eingesetzten SAP-Lösungen dienen. Diese Pakete sind in den WArtungsverträgen ActiveEmbedded und MaxAttentionm bereits integriert.

SAP customer connection Program

Dieser vertrag ist der Wartungsvertrag mit dem niedrigsten support-Level. Über diesen ist mir persönlich jetzt nicht viel bekannt.

SAP ONE Support Program

Das SAP ONE Programm setzt auf den SAP Enterprise support Wartungsvertrag auf und ist daher auf Kunden dieses Wartungsvertrages zugeschnitten. Dabei sollen die Support-Leistungen für SAP on-premise-Lösungen (also SAP-Lösungen, die auf kundeneigener Hardware betrieben werden) und die support-Leistungen für SAP Cloud-Lösungen (also Lösungen, die auf SAP-Hadware betrieben werden) vereinheitlicht werden. Dadurch soll es einfacher für Kunden sein, hybride Umgebungen zu betreiben unmd dafür Support zu erhalten.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

Home-IT, IT, Serveradministration Linux

PXE Boot Server auf Synology Diskstation trotz DSM 3 und DHCP Server auf FritzBox

13. Dezember 2014 DaFRK 2 Kommentare

Heute habe ich mir eine echte Challenge ausgesucht. Ich möchte einen DHCP-SErver auf meiner Synology Diskstation, obwohl ich eine DS107+ habe und daher nicht auf dSM 4.2 upgraden kann – und außerdem möchte ich den DHCP Server meiner Fritz!Box behalten.

TFPT Server

Ein PXE server braucht immer zu allererst einen TFTP server.

ipkg update

ipkg install tftp-hpa

Wir entfernen außerdem einen nicht benötigten xinetd, da wir mit dem inetd arbeiten werden.

ipkg --force-depends remove xinetd

Wir müssen sicherstellen, dass der IP-Adressbereich, von dem wir später den tFTP Server aufrufen wollen, in der konfiguration des inetd mit enthalten ist. In meinem Beispeil ist mein lokales LAN das Netz 192.168.2.XXX – die Konfiguration lässt folgende Netzte zu

Warning: the current only_from configuration in inted.conf is
only_from = localhost 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

Also passt es.

Wir editieren außerdem die /etc/inted.conf

tftp dgram udp wait root /opt/sbin/in.tftpd /opt/sbin/in.tftpd -s /opt/tftpboot -m /opt/etc/tftp_remap.conf

und schreiben in die Datei /opetc/etc/tftp_remap.conf

rg \\ /

wir starten nun den inetd neu

/usr/syno/etc/rc.d/S03inetd.sh restart

Wir testen nun unseren TFTP Server Dazu erstellen wir eine testdatei im verzeichnis /opt/tftpboot

cd /opt/tftpboot

echo 'hello world' >> test.txt

Wir veruschen nun von einem Windows-Client aus in der eingabeaufforderung diese test.txt zu bekommen mittels

tftp <diskstation_ip> get test.txt

Falls der tftp-Befehl in Windows nicht installiert ist, muss man ihn unter Systemsteuerung / Programme installieren / Windows-Funktionen aktivieren oder deaktivieren / TFTP-Client nachinstajllieren

Wenn der TFTP funktioniert, kriegfen wir so eine Meldung

DHCP Server installieren

Wir brauchen einen DHCP Server, der den PXE-Clients, wenn Sie nach images fragen, die nötigen Images zuteilt. Wenn wir einen solchen DHCP normal aufsetzen, würde er normalerweise mit dem DHCP-Server usnerer Fritz!Box in Konflikt geraten. Wir können den DHCP-Server unserer diskstation aber so konfigurieren, dass er nur PXe-Optionen bereitstellt und die anderen Optionen vom DHCP Server unserer Fritz!Box bereitgestellt werden. so kommen sich die beiden DHCP Server nicht in die Quere.

Wir installieren den DHCP mit

ipkg install dhcp

und editieren die Konfigurationsdatei

vi /opt/etc/dhcpd.conf

Jetzt kommt es darauf an. Wenn Ihr in Zukunft ausschließlich den DHCP server der Diskstation nutzen wollt, um IP Adressen und PXE Optionen gleichzeitig an eure clients zu übertragen, sieht die Konfiguration wie folgt aus:

ddns-update-style none;

ddns-updates off;



allow booting;

allow bootp;



# hier für gewöhnlich die Adresse des Routers eintragen.

option domain-name-servers 192.168.2.1;



# euer Subnetz und Maske

subnet 192.168.2.0 netmask 255.255.255.0 {



    option subnet-mask 255.255.255.0;

    option routers 192.168.2.1;

    option domain-name "fritz.box";

    option perform-mask-discovery false;

    option router-discovery false;



    # IP-Bereich den ihr für den DHCP-Server nutzen wollt

    range dynamic-bootp 192.168.2.100 192.168.2.200;

    default-lease-time 21600;

    max-lease-time 43200;

    # IP der Diskstation

    next-server 192.168.2.30;

    # Dateiname des Programmes für das Bootmenü

    filename "pxelinux.0";

}

Wollt ihr hingegen Synology-DHCP und FritzBox!-DHCP nebeneiannder laufen lassen, müsst ihr so konfigurieren:

ddns-update-style none;

ddns-updates off;



allow booting;

allow bootp;



# hier für gewöhnlich die Adresse des Routers eintragen.

option domain-name-servers 192.168.2.1;



# euer Subnetz und Maske

subnet 192.168.2.0 netmask 255.255.255.0 {



    option subnet-mask 255.255.255.0;

    option routers 192.168.2.1;

    option domain-name "fritz.box";

    option perform-mask-discovery false;

    option router-discovery false;



    # IP-Bereich den ihr für den DHCP-Server nutzen wollt

    range dynamic-bootp 192.168.2.11 192.168.2.11;

    default-lease-time 21600;

    max-lease-time 43200;

    # IP der Diskstation

    next-server 192.168.2.30;

    # Dateiname des Programmes für das Bootmenü

    filename "pxelinux.0";

}

Wenn irh alles so eingerichtet habt, dass Ihr den DHCP server dedr Disktation anstelle dem der Fritz!Box haben wollt, müsst Ihr den DHCP Server der FritzBox jetzt beenden und gleich danach den DHCP server der diskstation restarten mit

/opt/etc/init.d/S56dhcp

beim restarten bekommt ihr warhschienlich den fehler, dass der Ordner /opt/var/run nicht existiert. Also erstellt ihr ihn und startet den SErver nochmal neu

mkdir /opt/var/un

/opt/etc/init.d/S56dhcp

Vorbereiten der PXE Umgebung

Wir müssen uns jetzt das sogenannte syslinux-apket herunterladen

cd /tmp

wget --no-check-certificate http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-4.04.tar.gz

tar xvzf /tmp/syslinux-4.04.tar.gz

cp /tmp/syslinux-4.04/core/pxelinux.0 /opt/tftpboot

cp /tmp/syslinux-4.04/com32/menu/menu.c32 /opt/tftpboot

mkdir /opt/tftpboot/pxelinux.cfg -p

Wenn irh beim downlaod einen Fehler bekommt HTTPS support not compoiöled in, müsst ihr noch den SSL-Support für wget nachinstallieren.

ipkg remove wget

ipkg install wget-ssl

Wir erstellen eine Default-Konfigurationdatei

vi /opt/tftpboot/pxelinux.cfg/default

und schreiben hinein:

DEFAULT menu.c32

PROMPT 0

NOESCAPE 0

TIMEOUT 3000



MENU TITLE Bootmenue



LABEL local

MENU LABEL ^1 - Booten von lokaler Festplatte

LOCALBOOT 0

Vorbereiten der Installation eines Linux-Betriebssystems

Nun wollen wir unseren PXE-Server tsten, indem wir Ubuntu darauf installieren.

Dazu müssen wir uns zuerst die Netboot-Version von Ubuntu runterladen. Das ist ein Ubuntu-Image, welcehes speziell für eine Installation per PXE vorberietet wurde

cd /tmp

wget --no-check-certificate http://de.archive.ubuntu.com/ubuntu/dists/trusty/main/installer-i386(oder amd64)/current/images/netboot/netboot.tar.gz

tar xvzf netboot.tar.gz

cp ubuntu-installer/ -R /opt/tftpboot

Wenn die Datei nicht egfunden werden kann, könnt ihr euch über euren Webbrowser bis zum passenden zwei durchhangeln

Und nun müssen wir noch einen Eintragam Ende unserer default-Konfigburationsdatei für diese Image vornehmen

LABEL Ubuntu

  MENU LABEL ^2 - aktuelles Ubuntu installieren i386 (Internet)

    kernel ubuntu-installer/amd64/boot-screens/vesamenu.c32

    append ubuntu-installer/amd64/boot-screens/menu.cfg

Beliebiges Image per PXE booten

Gut, jetzt wissen wir schonmal, wie wir ein Image booten, welches speziell für PXe vorbereitet wurde. doch wie booten wir jetzt von einem x-beliebigen Image?

Nun, wenn ihr genau aufgepasst habt, dann handelte es sich bei dem netboot-Ubuntu um den Inhalt, den man genau so gut in eine .iso-Datei verpacken hätte können, nur eben in einer .tar.gz-Datei anstatt einer .iso. Der Entscheidende Faktor, der bestimmt, ob eine .iso-Datei also bootfähig ist, ist, ob sie die nötigen .c32- und .cfg-Dateien für einen PXE-Boot enthält. Wie oben bereits dargestellt, haben wir das netboot-Ubuntu mit den Dateien vesamenu.c32 und menu.cfg in die PXE-Umgebung eingebunden. diese dateien definieren das Menü und das Verhalten des Images, wenn der Client das Image in seinem PXE-Boot-Screen aufruft.

Wenn eine solche iso die entsprehcenden Dateien enthält, können wir das iso einfach in das tftpboot-Verzeichnis mounten und in unserer default.cfg einen entsprechenden Verweis auf die ..c32 und .cfg-Dateien in diesem gemounteten iso machen. .Dann können wir davon booten.

Als erstes müssen wir das jeweilige Image downloaden. Ich nehme jetzt einfach mal das Beispiel Memtest. Ich downloade das iso mit wget und speichere sie in einem neuen Ordner /tftpboot/images

wget <adresse_zu_memtest>

mkdir /opt/tftpboot/images

cp memtest86+--5.01.iso /opt/tftpboot/images

Jetzt erstelle ich einen Ordner, in den ich das Image mounten werde, und mounte die iso in diesen Ordner

mkdir /opt/tftpboot/memtest

mount /opt/tftpboot/images/memtest86+--5.01.iso /opt/tftpboot/memtest -o loop -t iso9660

Wenn ihr beim Mounten den Fehler bekommt mount: mounting /dev/loop0 failed: No such device

Müsst ihr folgendes machen

insmod /lib/modules/isofs.ko

und eventuell dazu noch

insmod /lib/modules/loop.ko

sollte Letzteres nicht gehen, versucht das mounten einfach trotzdem nochmal.

Jetzt wo unser Image gemountet ist, können wir davon genau so booten. Dazu brauchen wir allerdings wieder einen Eintrag in unserer default.cfg. Damit wir diese Einträge machen können, müssen wir erst die menu.c32 und die menu.cfg finden. wir gehen also in /opt/tftpboot/memtest und suchen diese Dateien.

Überraschenderweise werden wir feststellen, dass dieses Image nur einen Ordner boot mit den beiden Dateien boot.cat und memtest.img enthält. Das ist aber kein Grund zur Verzweiflung, das bedeutet einfach, dass dieses Image eine andere Methode nutzt. Wir müssen nur die .img-Dateiendung von memtest.img entfernen

cp memtest.img memtest

und in unsere default.cfg einfach nur folgenden Eintrag machen.

 LABEL Memtest

      MENU LABEL Memtest

      kernel memtest/memtest

Ihr werdet feststellen, was wir hier machen. In den vorigen Einstellungen haben wir mit dem Statement kernel die .c32-Datei ausgeführt. Diesmal führen wir die memtest-Binary mit dem Statement aus. Bei jedem PXE boot geht es also darum, mit dem Statement kernel den Binärcode eines Iso-Images auszuführen, der dafür zuständig ist, dass das Iso im PXE-Mode booten kann. An diese Binary kann man mit dem Statement append dann beispielsweise eine .cfg-Datei anhängen, dei weitere Konfigurationen enthält.

Ihr bekommt eventuell einen Fehler, dass ihr die memtest.img nicht umbenennen könnt, weil ihr ein read only file system habt. Klar – denn ihr habt die .iso gemountet die .iso lässt sich ohne weiteres nicht beschreiben.

In so einem Fall mountet man dann ein image nicht mehr, sondern man kopiert es. Wir mounten unser Image nun also in einen anderen Ordner und kopieren dann den inhalt der .iso in unseren Memtest ordner. Dazu müssen wir vorher memtest aus unserem alten Ordner unmounten.

umount -l /opt/tftpboot/memtest

mkdir /opt/tftpboot/tempmount

mount /opt/tftpboot/images/memtest86+--5.01.iso /opt/tftpboot/tempmount -o loop -t iso9660

cp -rpf /opt/tftpboot/tempmount/boot/boot.cat /opt/tftpboot/memtest/

cp -rpf /opt/tftpboot/tempmount/boot/memtest.img /opt/tftpboot/memtest/memtest.img

Wenn ihr biem nue mounbten den fehler bekommt

mountin /dev/loop0 on /opt/tftpboot/tempmount/ failed: device or resource busy, müsst ihr herausfinden, welcher prozess noch auf die iso zurgeift und ihn beenden. das geht mit dedm befehl lsof

Es kann sein, dass wenn ihr nun veruscht, Memtest86+ zu booten, sich die binary aufhängt und ihr nur einen schwarzen bildschirm seht. in diesem Fall müssen wir eine Andere Version von memtest installieren.

wget http://www.memtest.org/download/5.01/memtest86+-5.01.bin.gz

gzip -d memtest86+-5.01.bin.gz

wir kopieren nun die Datei memtest86+-.01.bin in unseren memtest ordner und nennen diese memtest. Nun müsste es gehen.

Zweite Übung: ct Bankix

Nun wollen wir eine Live-CD einbinden, um von dieser zu booten. c’t Bankix ist ein livesystem welches auf anonymes und möglichst sicheres Surfen im Internet zugeschnitten wurde. Der Name drückt hierbei aus, dass dieses Livesystem besonders zum Online-Banking entwickelt wurde. Wir wollen die Möglichkeit haben, von diesem image via PXE zu booten.

Als erstes downloaden wir c’t Bankix in unser images-Verzeichnis. Das geht wieder über wget. Danach müssen wir das image wieder in unser tempmount-Verzeichnis schaffen. Dazu ist es eventuell erforderlich, dass wir zuvor das memtest-iso unmoutenn

umount /dev/tempmount

mkdir /opt/tftpboot/bankix

mount /opt/tftpbot/images/bankix.iso /opt/tftpboot/tempmount -o loop -t iso9660

Nun suchen wir wieder ein Datei, die wir später mit dem kernel-Statement starten können. In idesem Fall handelt es sich um die Datei vmlinuz, die sich im Unterordner casper innerhalb der iso befindet. Wir müssen also lediglich die Datei vmlinux in unseren ordner /opt/tftpboot/bankix kopieren. Desweiteren brauchen wir noch die datei initrd.lz, die sich ebenfalls im unterordner casper befindet

cp /opt/tftpboot/tempmount/casper/nopae/initrd.lz /opt/tftpboot/bankix

cp /opt/tftpboot/tempmount/casper//nopae/vmlinux /opt/tftpboot/bankix

Kurz zur Erklärung, warum wir uns die Dateien aus dem Unterverzeichnis nopae holen. PAE steht für Physical Address Extension und soll es 32-Bit-Systemen ermöglichen, auf einem 32-Bit-System mit mehr asl 4 GB RAM zu laufen. Da ich einen 64-Bit-CPU-Rechner habe, brauche ich keine PAE.

Das war es aber noch nicht. Denn c’t Bankix braucht während des Boot-Vorgangs andere Bestandteile des .isos, die wir ihm irgendwie bereitstellen müssen. die beste möglichkeit hierfür ist ironischerweise nicht TFTP, sondern NFS.

Damit das funktioniert, muss in der diskstation.weboberfläche unter Bedienfeld / Win/Mac/NFS der NFS-Dienst eingeschaltet sein

2014-12-12_03h05_57

Jetzt m,üssen wir erstmal sicherstellen, ob es bereits ein Sartksirpt für den NFSd gibt.

cd /usr/syno/etc/rc.d

ls | grep nfs

Wenn es hier die Datei S83nfsd.sh gibt, müssen wir nichts machen. Gibt es stattdessen die S83nfsd.sh.sample, müssen wir das .sample mit mv wegmachen.

Wir müssen jetzt einen Ordner für unsere künftigen NFS-Freigaben erstellen. Das mache ich unter /data/nfs

mkdir /data

mkdir /data/nfs

mkdir /data/nfs/bankix

Wir kopieren die beim Bootvorgang benötigten Verzeichnisse in den Ordner rein, der später per NFS freigegeben werden soll

cp -a /opt/tftpboot/tempmount/casper/ /opt/tftpboot/tempmount/isolinux /opt/tftpboot/tempmount/preseed/ /dat/nfs/bankix

Jetzt können wir das iso endgültig aushängen

umount /opt/tftpboot/tempmount

Jetzt müssen wir konfigurieren, dass die entsprechenden Verzeichnisse per NFS freigegeben werden. Das geht über die Datei /etc/exports

vi /etc/exports

Wir erstellen darin folgenden inhalt

/data/nfs/bankix 192.168.2.30/24(ro)

Jetzt müssen wir den NFSd neu starten

/usr/syno/etc/rc.d/S83nfsd.sh restart

Jetzt bearbeiten wir wieder unsere default-Datei

LABEL ctbankix

menu label ct Bankix 12.04.4

kernel /bankix/vmlinuz

append nfsroot=192.168.2.30:/data/nfs/bankix netboot=nfs ro BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/bankix/initrd.lz quiet splash debian-installer/language=de console-setup/layoutcode=de

Dritte Übung: Gparted

Um GParted als PXE-Boot zum Laufen zu bringen, müssen wir die GParted Live Zip in einer Verison von 0.3.7-2 oder später downloaden.

wget http://downloads.sourceforge.net/project/gparted/gparted-live-stable/0.20.0-2/gparted-live-0.20.0-2-amd64.zip?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fgparted%2Ffiles%2Fgparted-live-stable%2F0.20.0-2%2F&ts=1418355119&use_mirror=cznic

unzip gparted-live-0.20.0-2-amd64.zip

Wir erstellen uns wieder einen Ordner für gparted in unserem tftpboot-Ordner und kopieren dort die benötigten Dateien vmlinux und initrd.img rein

mkdir /opt/tftpboot/gparted

cp /gparted/live/{vmlinuz,initrd.img} /opt/tftpboot/gparted

GParted braucht außerdem einen Webserver. Den haben wir ja auf usnerer Diskstation. Das standardverzeichnis dafür ist /volume1/web. Wir brauchen nämlich noch die Datei filesystem.squash, die wir in den Ordner /volume1/web kopieren müssen.

cp /gparted/live/filesystem.squashfs /volume1/web

chown nobody:administrators /volume1/web/filesystem.squashfs

Jetzt editieren wir wieder unsere default-Datei

LABEL GParted Live

MENU LABEL GParted Live

kernel gparted/vmlinuz

append initrd=gparted/initrd.img boot=live config union=aufs noswap noprompt vga=788 fetch=http://diskstation/filesystem.squashfs

Vierte Übung: CloneZilla

wir brauchen auch hier eine live zip mit einer Verison von 1.2.0-25 oder später.

wget http://downloads.sourceforge.net/project/clonezilla/clonezilla_live_stable/2.3.1-18/clonezilla-live-2.3.1-18-amd64.zip?r=http%3A%2F%2Fclonezilla.org%2Fdownloads%2Fdownload.php%3Fbranch%3Dstable&ts=1418357102&use_mirror=heanet

unzip clonezilla.zip

Wir müssen wieder die vmlinuz und die initrd.img aus dem live-verzeichnis kopieren. Auch hier leigt wieder eine filesystem.squashfs, die wir in einen webserverordner reinamchen müssen. Diesmal erstelle ich in /volume1/web einen extra ordner /volume1/web/clonezilla dafür. dort kommt die datei dann rein

mkdir /opt/tftpboot/clonezilla

cp /clonezilla/live/{vmlinuz,initrd.img} /opt/tftpboot/clonezilla/

mkdir /volume1/web/clonezilla

cp /clonezilla/live/filesystem.squashfs /volume1/web/clonezilla

chown -R nobody:administrators /volume1/web/clonezilla

und in der default-Datei schreiben wir dann rein

LABEL CloneZilla

MENU LABEL CloneZilla

kernel clonezilla/vmlinuz

append initrd=clonezilla/initrd.img boot=live config noswap nolocales edd=on nomodeset ocs_live_run="ocs-live-general" ocs_live_extra_param="" keyboard-layouts="" ocs_live_batch=2no" locales=""vga=788 nosplash noprompt fetch=http://diskstation/clonezilla/filesystem.squashfs

Fünfte Übung: Hirens Boot CD

Bisher waren alle Images, die wir probiert haben, auf irgendeine Art und Weise dafür vorgesehen, über PXe gebootet zu werden. Diesmal probieren wir eine kniffligere Angelegenheit: Wir nehmen die Hiren’s boot Cd, welche nicht über binaries wie beipsielsewise vmlinuz o. Ä. verfügt und daher mit einer anderen Methode eingebunden werden muss.

Als erstes brauchen wir wieder die Hirens Boot CD. diese entpacken wir danach wieder mit unzip. Die erahltene iso kopieren wir in unseren /opt/tftpboot/images Ordner.

In dieser Übung wollen wir die iso direkt per PXE booten. Dazu brauchen wir aus unserem syslinux-4.04.tar.gz-Paket, welches wir weiter oben schonaml runtergeladen haben, eine binary namens memdisk. Diese wird traditionell in den Ordner pxelinux.cfg/roms kopiert, den wir erst erstellen müssen

mkdir /opt/tftpboot/pxelinux.cfg/roms

cp /tmp/syslinux-4.04/memdisk/memdisk /opt/tftpboot/pxelinux.cfg/roms

chmod 700 /opt/tftpboot/pxelinux.cfg/roms/memdisk

Wenn wir jetzt die Hirens Boot CD booten wollen, müssen wir in unserer default einen derartigen Eintrag vornehmen

LABEL HIRENSBOOTCD

MENU LABEL Hiren's Boot CD 15.2

kernel pxelinux.cfg/roms/memdisk

append iso initrd=/images/hirens.iso raw

Sechste Übung: Windows 7 / Windows 8 PE-SE booten

Die Windows 7 und Windows 8 PE-SE Umgebungen sind exzellente Windows-Live-Systeme die man verwenden kann, wenn man nicht von der Festplatte booten kann oder will (aus sicherheitsgründen beispielsweise), aber in einer windows-Umgebung noch was am Dateisystem machen will. Der Unterschied zu den normalen PE-Umgebungen ist, dass man bei ihnen eine grafische Oberfläche hat und bereits einige sinnvolle Tools vorinstalliert sind.

Damit man eine solche Pre-Boot-Environment erstellen kann, braucht man eine Windows 7 oder Windows 8 DVD und muss dessen inhalte in einen Ordner kopieren. Beispielsweise könnt ihr die DVD in euren Windows-CP einlegen und unter C:\ einen Ordner ISO erstellen, in welchen ihr dann die inhalte der DVD reinkopiert.

Wenn ihr einen Windows 7 PE erstellen wollt, erstellt ihr außerdem einen Ordner C:\WIN7PE, bei Windows 8 entsprechend C:\WIN8PE.

Jetzt müsst Ihr euch entweder Win7PE SE oder oder Win8PE SE herunterladen. Den inahlt des heruntergeladenen Archivs entapckt Ihr in euren Ordner C:\WINXPE

Nun müsst Ihr den Builder starten unter C:\WINXPE\WinXPESE82_Builder.exe

Nun müsst ihr die Quelle auswählen, wo Ihr die Inhalte der DVD hinkopiert habt. Dazu wählt ihr im Menü des bulders Source und bei Source Directory dann C:\ISO. Klickt nun auf den blauen Button oben rechts PLAY und wartet bis das ISO erstellt wurde.

Jetzt kopiert ihr die Iso in euren tftpboot/images ordner auf der diskstation und probiert diese bieden Einträge aus, einer der beiden muss funktionieren

LABEL WINXPE-SE

MENU LABEL Windows X PE-SE

kernel pxelinux.cfg/roms/memdisk

append iso initrd=/images/winxpe.iso raw



oder



LABEL WINXPE-SE

MENU LABEL Windows X PE-SE

KERNEL pxelinux.cfg/roms/memdisk

APPEND iso raw

INITRD images/winxpe.iso

Siebte Übung: Windows 7 / 8 PE booten zur Vorbereitung einer autoamtischen Windows INstallation

OK, jetzt als Sahnehäubchen noch das Starten einer Windows 7 Installations-DVd per PXE

wir brauchen ein .iso einer Win7-installations-DVD. Leider reicht es nicht, diese in unseren images-Ordner zu kopieren und dann einen derartigen Eintrag in der defaults-Datei zu machen.

LABEL Windows7

MENU LABEL Installiere Windows 7

kernel pxelinux.cfg/roms/memdisk

append iso initrd=/images/win7.iso raw

Wenn wir das so tun, werden wir beim Booten selber einen FEhler bekommen, dass nicht genug memory (arbeitsspeicher) zur Verfügung steht, um das image vorhalten zu können. Denn memdisk macht nichts anderes, als das gesamte Image in den Arbeitsspeicher reinzuladen. Und dann muss aber das Installations-Betriebssystem auch noch in den Arbeitsspeicher. Ich habe eine windows 7 oder windows 8 installations-DVD mit dieser Methode nicht mal auf einem Rechner mit 4 GB RAM zum booten bekommen.

Die Methode, funktioniert und die auch empfehlenswerter ist, ist wieder eine Windows Pre-Boot-Environment-DVD zu erstellen. Windows PE wird dabei per PXe gebootet und dient als Live-System, von dem aus wir dann die Windows-installation von den inhalten des eigentlichen Windows-Images starten. Das bedeutet, wir brauchen einmal eine .iso für die WinPE-Liveumgebung und einmal eine .iso von der Original-Windowsinstallations-DVD und müssen erstere über PXe booten und Letztere über das Netzwerk bereitstellen.

Ich werde in diesem Teil nur erläutern, wie man Windows PE in einem anderen Weg als den oben beschriebenen per PXE bootet. Das unbeaufsichtigte installieren von Windows 7 werde ich in einem gesonderten Artikel einmal beschreiben.

für eine Windows 7 Umgebung rbauchen wir dazu ein Tool von microosft, das windows automated installation Kit für Windows 7.

Da es Sinn macht, in das installationsmedium das SErvice Pack 1 zu integrieren, müssen wir entsprehcende Erägnzungen zu unserem Windows AIK runterladen, die uns das integrieren von SP1 ermöglichen.

Die inhalte dieser beiden .iso Dateien müssen wir jetzt installieren. zuerst bibnden wir also das Win7AIK ein und installieren dort die entsprecehnde Software über den installationsassistenten.

ich musste die .iso dazu auf eien DVD Brennen, weil hier ein kompliziertes UDF-Dateisystem drauf ist, welches mein imaging-Tool nicht lesen konnte.

Die SP1 Integration hingegen konnte ich einfach mounten. Nach der installation des AIK können wir die SP1 integration mounten. Wir bruachen jetzt eine Eingabeaufforderung, die wir als Administrator ausführen. Wir m,üssen jetzt den inhalt deds gemounteten SP1 integration ISOs in den Ordner C:\Program Files\Windows AIK\Tools\PETools reinkopieren. Dadurhc integreiren wir SP1 in die bestehende AIK-Umgebung.

C:\Windows\system32>xcopy E:\*.* /s /e /f "C:\Program Files\Windows AIK\Tools\PETools"

Wenn wir jetzt einfach nur eine installations-Dvd ohne weitere Treiber und Programme erstellen wollen, müssen wir die sobene kopierte Datei copype.cmd ausführen. durch diese Skript werden alle bneötigtne Datieen für das ISO-image berietgestellt. Das skript benötigt PArameter, und zwar die erzielte Systemarchitektur (x86, ia64 oder amd64) sowie den Zielpfad

C:\Windows\system32>"C:\Program Files\Windows AIK\Tools\PETools\copype.cmd" amd64 C:\WinPE_amd64

Wichtig: Der Ordner C:\WinPE_amd64 darf vor Ausführen des Skriptes nicht existieren!

Unte rden kopierten Dateien in WinPE_amd64 befindet isch nun auch eine Datie namens winpe.wim. Das ist das WIM-image des Live-Systms. Dieses müssen wir jetzt noch umkopieren, damit das System von einem Live-System zu einem vollwertigen Boot-System wird

copy C:\WinPE_x86>copy C:\WinPE_x86\winpe.wim C:\WinPE_x86\ISO\sources\boot.wim

Jetzt können wir ein ISO-image mit der oscdimg.exe erstellen

C:\WinPE_x86>"C:\Program Files\Windows AIK\Tools\amd64\oscdimg.exe" -n -bC:\WinPE_amd64\etfsboot.com C:\WinPE_amd64\ISO C:\WinPE_amd64\Win7PE_x64.iso

Dieses soeben erstellte ISO wollen wir nun testhalber schonmal zum Booten freigeben. Diees kopieren wir in unseren /opt/tftpboot/images Ordner und erstellen dann den oben aufgeführten Eintrag in unserer default-Datei mit Abänderung des Dateinamnes der .iso-Datei.

Sie werden feststellen, dassdas noch nicht gnaz das ist, was wir wollen.

Zunächst wollenw ri veruschen, zusätzliche programme und Treiber einzubinden. Wir löschen unser verzeichznis C:\winPE_amd64 wieder.

wir erstellen das Verzeichnis neu mit dem copycmd skript

C:\Windows\system32>"C:\Program Files\Windows AIK\Tools\PETools\copype.cmd" amd64 C:\WinPE_amd64

Wenn der Befehl auf einmla nicht geht, müsst ihr auch den xcopy-Vorgang weiter oben nochmal wiederholen.

Jetzt müssen wir das winpe.wim-Bootimage mounten, um darin Dateien, Programme und Treiber hinzufügen zu können.

"C:\Program Files\Windows AIK\Tools\amd64\Servicing\Dism.exe" /Mount-Wim /WimFile:C:\WinPE_amd64\winpe.wim /Index:1 /MountDir:C:\WinPE_amd64\mount

Das image ist jetzt in den Unterordner mount unseres WinPE-Ordners eingebunden. Wir erstellen in diesem gemounteten Verzeichnis nun einen Ordner, inw elchem die Tools, Treiber und Dateien abgelegt werden sollen.

mkdir C:\WinPE_amd64\mount\Tools

Wir erstellen in diesem Ordner nun eine Konfigurationsdatei für imageX, das Tool welches wir später zum Neuschreiben des botoimages verwenden werden., Die Datei trägt dne namen wimscript.ini und hat den folgenden inhalt

[ExclusionList]

ntfs.log

hiberfil.sys

pagefile.sys

"System Volume Information"

RECYCLER

Windows\CSC



[CompressionExclusionList]

*.mp3

*.zip

*.cab

\WINDOWS\inf\*.pnf

Es kann sein, dass ihr die Datei dazu erst außerhalb des Ordners erstellen und sie dann nachträglich reinkopieren müsst.

Jetzt kopieren wir weitere Software, die wir in unserer WinPE-umgebung haben wollen, in den Tools-Ordner. Dabei machen natürlich nur portable Programme sinn, die ohne installation auskommen.

Nun erstellen wir noch einen Ordner C:\WinPE_amd64\Drivers. in diesen Ordner kopieren wir nun alle Treiber, die wir später einbinden wollen, am besten als .inf-Datei. Wenn Sie den Treiber als Installer.exe runtergeladen haben, müssten Sie in den Unterverzeichnissen der .exe oder des .rar-/.zip-ARchivs nach .inf und .cab-Dateien suchen .Vorsicht: Installer enthalten oft die Treiber für mehrere mögliche Hardwarekonfiguraitonen. Es gilt herauszufinden, welche der .inf und .cab-Dateien für die eigenen HArdwarekomponenten sind.

Sollten Sie Treiber platziert haben, können Sei die nun folgendermaßen in das image einbinden

C:\WinPE_x86>"C:\Program Files\Windows AIK\Tools\amd64\Servicing\Dism.exe" /Image:C:\WinPE_amd64\mount /Add-Driver /Driver:C:\WinPE_amd64\Drivers /Recurse

Jetzt speichern wir die Änderungen am Boot-Image.

"C:\Program Files\Windows AIK\Tools\amd64\Servicing\Dism.exe" /Unmount-Wim /MountDir:C:\WinPE_amd64\mount /Commit

die Änderungen sind jetzt im winpe.wim-Image enthalten. Wir koieren jetzt wie bereits bekannt das winpe.wim-Image in den sources-Unterordner als Boot-image und erstellen dei .iso

C:\WinPE_x86>copy C:\WinPE_amd64\winpe.wim C:\WinPE_amd64\ISO\sources\boot.wim

C:\WinPE_x86>"C:\Program Files\Windows AIK\Tools\amd64\oscdimg.exe" -n -bC:\WinPE_amd64\etfsboot.com C:\WinPE_amd64\ISO C:\WinPE_amd64\WinPE_x86.iso

Nun habt ihr die Grundvoraussetzungen für das booten einer Windows 7 installations-DVD geschaffen.

Windows 8.1

Nun wollen wir uns der alternativen Erstellung einer Windows 8.1 PXE-Umgebung widmen.

Für Windows 7 musten wir das sogenantne Windows Automated installation Kit (AIK) installieren. Bei Windows 8 heißt das paket anders, nämlich Windows Assessment and Deployment Kid (/ADK).

Die instllationm ist ziemlich straight-forward. Nach der installation steht uns die sogenannte Umgebung für Berietstellungs- und imageerstellungstools zur Verfügung, welche wir als Administrator ausführen. das Prozerdddere ist görßtnteils gleich wie bei Windows 7. Als ertes müssen wir wieder die Inhalte de rUmgebung in einen Ordner kopieren.

C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools>cd "..\Windows Preinstallation Environment"

C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Preinstallation Environment>copype.cmd amd64 "C:\WinPE_amd64"

wenn wir jetzt noch Treiber Programme und Dateien einfügen wollen, müssen wir das Image mounten

C:\WinPE_x86>"C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\x86\DISM\dism.exe" /Mount-Wim /WimFile:"C:\WinPE_x86\media\sources\boot.wim" /Index:1 /MountDir:"C:\WinPE_x86\mount"

wir erstellen wieder einen mount-Ordner

C:\WinPE_x86>mkdir "C:\WinPE_x86\mount\Tools"

in diesn Ordner kopieren wir imagex

C:\WinPE_x86>copy "C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\x86\DISM\imagex.exe" "C:\WinPE_x86\mount\Tools"

und erstellen dafür wieder eine wimscript.ini im Ordner Tools mit folgendme inhalt

[ExclusionList]

ntfs.log

hiberfil.sys

pagefile.sys

"System Volume Information"

RECYCLER

Windows\CSC



[CompressionExclusionList]

*.mp3

*.zip

*.cab

\WINDOWS\inf\*.pnf

Wir erstellen wieder einen Ordner Drivers

C:\WinPE_x86>mkdir "C:\WinPE_x86\Drivers"

Nun fügen wir wieder unsere Treiber ein. mit foglendem Befrhel könnten wir sie anschließend einlesen.

C:\WinPE_x86>"C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\x86\DISM\dism.exe" /Image:"C:\WinPE_x86\mount" /Add-Driver /Driver:"C:\WinPE_x86\Drivers" /Recurse

falls wir Treiber etc. hinzugefügt haben, speichernw ir das bootimage ab

C:\WinPE_x86>"C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\x86\DISM\dism.exe" /Unmount-Wim /MountDir:"C:\WinPE_x86\mount" /Commit

nur, dass wir nach diesem Kopiervorgang bereits eine Boot-CD verstellen können.

:\WinPE_x86>"C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\amd64\Oscdimg\oscdimg.exe" -m -o -u2 -udfver102 -bootdata:2#p0,e,b"C:\WinPE_amd64\fwfiles\etfsboot.com"#pEF,e,b"C:\WinPE_amd64\fwfiles\efisys.bin" "C:\WinPE_amd64\media" "C:\WinPE_amd64\WinPE_amd64.iso"

Jetzt kopieren wir das image wieder in unsere /opt/tftpboot/images und fügen folgendes in unsere pxelinux.cfg/default-Datei ein:

Home-IT, IT, Serveradministration Windows

Systemimages machen

9. Dezember 2014 DaFRK 1 Kommentar

Es kann oftmals sehr mühsam – und in einem Unternehmen auch sehr teuer – sein, ein System neu aufsetzen zu müssen. Denn in der Zeit, in der ein System neu aufgesetzt wird, kann nicht daran gearbeitet werden – klar. Dabei ist oftmals nicht das Schreiben der Daten auf die festplatte das Problem, sondern die manuell durhczuführenden Schritte wie die Installation von Software usw.

Häufige Gründe für eine Neuinstallation sind Fehler eines Systems – irgendein Dienst startet nicht mehjr oder verhält sich komisch – oder man wurde beispielsweise Opfer von Malware.

Wenn es dann so weit ist, ist der Ärger groß: In stundenlanger Musesarbeit muss das System von Null auf wieder hergerichtet werden.

Einen Großteil des Ärgers kann man sich sparen, wenn man in regelmäßigen Abständen von einem stabilen System ein Abbild erstellt. Dieses Abbild nimmt dabei die gesamten Daten auf der festplatte auf – also das Betriebssystem inklusive Inhalt, den Master Boot Record und die Partitionstabelle. Spielt man das Abbild auf eine gleich große oder größere Festplatte oder Partition, läuft das System wieder auf dem Stand des Abbilds, als wäre danach nie etwas geschehen. Man spart sich dabei zwar nicht das Bespielen der Festplatte mit den Daten, aber das manuelle Bearbeiten dieser Daten – und das macht immerhin den Großteil des Zeitaufwands auf.

Images von Desktop-PCs

Ein sehr gutes Tool, um solche Images zu machen ist clonezilla. Downloadet euch das Image in der Live Version und brennt es auf eine CD.

Wirklich sinn macht so eine Imagelösung nur dann, wenn man ein Gerät oder einen Server hat, der dauerhaft in Betrieb ist und der die Images aufnehmen kann, während man CloneZilla uaf dem abzubildenden Systerm laufen hat. Die kostengünstige Lösung dafür ist immer noch ein Network Attached Storage wie beispielsweise eine Synology Diskstation. Dort werden wir NFS-Freigaben einrichten, auf die wir unser CloneZilla-Image speichern werden.

Im CloneZilla wählt Ihr dann die zu sichernde Festplatte aus und im Anschluss die NFS-Freigabe oder externe Platte, auf die Ihr das Image speichern wollt. Wiederherstellen geht dann genau so einfach im umgekehrten Stil.

Images von einer NAS oder eines entfernt stehenden Linux-Systems

wenn Ihr viel Arbeit in das Aufsetzen und Konfigurieren eurer NAS oder einen Linux-Server gelegt habt, amcht es eventuell sinn, auch von diesem Gerät ein Festplattenabbild zu machen, damit Ihr das NAS nicht irgendwann neu konfigurieren müsst, wenn Ihr auf einen Fehler stoßt, die Platte versagt oder die NAS mit einem Virus infiziert wird.

Das Problem ist nur, dass man schlecht CloneZilla auf der NAS booten kann. es gibt kein DVd-Laufwerk und man müsste ansonsten erstmal einen PXE-Server aufsetzen, um das Image von CloneZilla über Netzwerk booten zu können – hat dann aber immer noch keine Möglichkeit, einen Bildschirm an die NAs anzuschließen und somit CloneZilla zu bedienen – und ohne Betriebssystem gibt es kein SSH.

Image über dd

eine gute MÖglichkeit, trotzdem ein image von der Festplatte zu machen, ist das Linux utility dd. dd ist eine System-Binary, die es ermöglicht, eine low-level Byte für Byte Kopie einer gesamten Festplattenpartition – oder einer gesamten Festplatte – in eine einzige Datei zu schrieben. Diese Datei ist sozusagen das Äquivalent eines Images.

Damit wir das Image sichern können, muss an die NAs eine extserne Festplatte angeschlossen sein – oder es muss im Netzwerk einen speicher geben, auf dem wir das image speichern können.

Nehemn wir an, ihr wollt ein Image der Partition /dev/hda1 machen.

dd if=/dev/hda1 of=/externe-platte/hda1.image

Wollt ihr dagegen die ganze Festplatte scihern:

dd if=/dev/hda of=/externe-platte/hda.image

Wenn Ihr nun eine Platte aus solch einem imag wiederherstellen wollt, müsst ihr folgendes eingeben:

dd if=/externe-platte/hda.image of=/dev/hda

Ihr dreht also einfach nur die beiden parameter um.

Wenn Ihr das Image noch komprimieren wollt, könnt Ihr anschileßend die .image-Datei in beispielswiese ein .tar.gz-Archiv packen. Beim Wiederherstellen müsst ihr das image natürlich dann vorher wieder entpacken.

Das ganze amcht natürlich nur dann sinn, wenn Ihr beim wiederherstellen eines Images den Befehl dd von einem anderen Linux-System aus eingebt als das, welches ihr zurückspielen wollt. Denn wenn Ihr vom selben System dd ausführt wie das, welches wiederhergestellt werden soll, ist es wahrscheinlich, dass das Kommando irgendwann abbricht. Schließlich überschreibt Ihr während des Vorgangs kritische Dateien, die das System nunmal braucht. Entweder ihr mountet die Platte der NAS über Netzwerk oder baut sie aus und setzt sie in ein anderes System ein – um sie dort zu mounten

Ein großer Nachteil von der sicheurngsmethode über dd ist, dass die Partition oder Festplatte, auf welche das Image wiederhergestellt werden soll, genau so groß sein muss wie damals bei der geimageten Platte/Partition. Bei Lösungen wie CloneZilla kann man immerhin auch auf Platten oder Partitionen zurückspielen, die größer sind.

Image über dump und restore

dump und restore sind zwei tools, die das jeweilige imagen oder wiederherstellen eines gesamten Systemstatus ermöglichen. Man kann sie oft über die einzelnen Paketdienste wie beispielsweise APT-Get, Zypper oder IPKG installieren. Auf einer Synology Diskstation installiert man sie bei installiertem IPKg biespielsweise über

ipkg install dump

ein Bakcup funktioniert dann so

dump -0uan -f /externe-platte/hda.image /

Für ein Restore müssen wir die Festplatte der NAS per Netzwerk oder durch Ausbauen in ein anderes System mounten und dann einspielen

restore -r -f /externe-platte/hda.image /mount-point-der-NAS-platte/

Home-IT, Serveradministration Windows

pyLoad zum Downloaden auf der Synology Diskstation oder Ubuntu Server

5. Dezember 2014 DaFRK 3 Kommentare

Es ist oftmals sehr mühsam, über einen Download-Manager auf dem eigenen Windows-Desktoprechner zu downloaden. DAfür sprechen zumindest viele Gründe. zum einen ist ein Desktoprechner nicht dafür ausgelegt, dauerhaft an zu bleiben und über nacht am Laufen gehalten zu werden, um nachts irgendwelche Downloads voranzutreiben. DAs verbraucht unnötig viel Strom. auch viele Festplatten sind nicht für große Datenmengen ausgelegt, die bei Downloads aber oft anfallen. Die kleine 250 GB SSD mit Downloads vollzumüllen, ist nicht gerade Sinn der Sache, warum man sich diese eigentlich angeschafft hat. Es ist aber auch ineffizient, den Rechner zusammen mit einer externen Festplatte dauerhaft zu betreiben.

Ein weiterer Vorteil, wenn der Downloader auf einem externen Gerät läuft: sie können auf Ihrem Desktop-Rechner per Proxy oder VPN anonym surfen, aber mit Ihrer normalen öffentlichen IP mit Full-Speed downloaden. Somit stören sie die Geschwindigkeitseinbußen bei Proxy oder VPN nicht mehr beim Download.

sinnvoller ist es, das Downloaden auf ein Gerät auszulagern, welches dauerhaft an bleiben kann und dabei nur sehr geringe Mengen Strom verbraucht. Was wäre dafür besser geeignet als ein Network Attached Storage Gehäuse mit einer großen Festplatte darin?

Die besten Produkte dieser Art sind meiner Meinung nach die Synology Diskstations. Diese haben mittlerweile die Vorreiterschaft auf dem Markt der Network Attached Storage Lösungen genommen und unterstützen mit pyLoad ein mächtiges tool zum Downloaden von Dateien über einen Downloadmanager – inklusive support zur Eingabe von Premium-Accounts.

Der clou: Sie müssen dabie nicht auf den Komfort des Suchen nach Downloads auf Ihrem Desktop-PC verzichten! Denn Sie können Browser-Addons wie beispielsweise FlashGot! für Firefox so einrichten, dass die Downloads an die pyLoad-Lösung auf Ihrem NAS-Gehäuse weitergeleitet werden.

Im Folgenden werde ich beschreiben, wie Sie pyLoad auf der Synology Diskstation oder auf einem Ubuntu Standardserver einrichten. Dabie setze ich für die Synology voraus, dass Sie bereits IPKG auf der Diskstation eingerichtet haben.

Installation auf der diskstation

Zunächst installieren wir alle benötigten Tools, die zur installation von pyload notwendig sind

ipkg update

ipkg install screen nano wget unzip unrar psmisc

ipkg install python py25-crypto py25-curl libcurl py25-openssl py25-django py25-pil tesseract-ocr tesseract-ocr-lang-eng ossp-js

Nun werden wir pyload selbst herunterladen. Das Tool ist leider nicht in das IPKG-Repository aufgenommen, sodass wir es manuell über wget herunterladen müssen. Die aktuelle version findet man unter http://get.-pyload.org/get/src – fügen Sie an die URL die aktuellste Version hinten an, beispielsweise 0.4.9, sodass Sie pyload letztendlich so installieren

cd /opt

wget http://get.pyload.org/get/src/0.4.9/

unzip pyload-src-v0.4.9.zip

rm pyload-src-v0.4.9.zip

cd pyload/

alternativ können Sie es aber auch über ipkg probieren

ipkg update

ipkg install pyload-v0.4.9-noarch.ipk

pyLoadCore -s

pyLoadCore -s ist nur notwendig, wenn Sie pyload über IPKG installieren. Dieser Befehl startet das Setup, welches Sie in der .zip-Version überspringen.

Egal, wie Sie pyLoad installiert haben, müssen wir pyLoad jetzt noch konfigurieren. Wir erstellen zuerst einen Ordner, in den wir später unsere Downloads haben wollen. In meinem Fall ist das /volume1/pyload.Dann wechseln wir in den unterordner /module/config.

Um den Ordner /volume1/pyload als Ordner für unsere Downloads festzulegen, machen wirim Ordner /opt/pyload/module/config folgendes:

mkdir /volume1/pyload

echo "volume1/pyload" >> configdir

Wir müssen in jedem Fall noch pyload ausführbar machen

chmod +x /opt/pyload/pyLoadCore.py

Nun starten wir zum ersten mla pyLoad

cd /opt/pyload

python ./pyLoadCore.py

Beim esten Afuruf erscheint ein Konfiguration-Assi, mit dessen Hiulfe wir beispielswiese ide sprache einstellen. außerdem wir ein Systemcheck durchgeführt. Wenn in diesem herauskommt, dass PyQt4 fehlt, könnt ihr das ignorieren – das wird nur für die GUI von pyLoad gebruacht, und die wollen wir ja nicht nutzen! Danach müsst ihr einen Benutzernamen und ein Login-Passowrt festlegen. Empfohlen wird, Reconnect auszuschalten. Schließlich wollt ihr ja nicht, dass euer Network Attached Storage dauernd neu verbindet! Denn dann würden alle anderen Dienste der NAS ständig außer Gefecht gesetzt. Das ist auch gleichzeitig die Stndardeinstellung.

Nach dem Setup wird pyLoad beendet. Es bringt auch nichts, pyLoad jetzt erneut aufzurufen, da diese instanz bvon pyLoad sich wieder beedndet, sobald wir das Konsolenfenster schließen. Deswegen müssen wir sicherstellen, dass wir pyLoad in Zukunft im Hintergrudn laufen lassne, so dass pyLoad unabhängig von geöffneten KOnsolenfenstern läuft. Das geht über screen. Manuell können wir pyLoad damit folgendermaßen im Hintergrund laufen lassen:

screen -dmS python /opt/pyload/pyLoadCore.py

Da wir das aber auch nicht jedesmal manuell, sondern automatisch bei jedem Systemstart machen wollen, erstellen wir ein Skript unter /etc/init.d/ mit dem Namen pyload, machen es ausführbar und verlinken das skript im Runlevel Init 2 (falls der Ordner /etc/rc2.d/ existiert) unter demd Namen S99pyload

vi /etc/init.d/pyload

#!/bin/sh

if [ -z "$STY" ]; then exec screen -d -m -S pyload /bin/bash "$0"; fi

cd /opt/pyload

python ./pyLoadCore.py

chmod +x /etc/init.d/pyload ln -s /etc/init.d/pyload /etc/rc2.d/S99pyload

wenn der Ordner rc2.d nicht vorahnden ist, empfiehlt es sich nicht, diesen manuell anzulegen. Stattdessen sollte man das Skript in die Datei /etc/rc.local eintragen

Falls Ihr einen Premiumaccount habt, wollt ihr den natürlich in pyLoad eintragen. Das geht über die Datei account.conf, die in unserem neuen Konfigurationsordner /volume1/pyload liegt. Wir editieren also die Datei /volume1/pyload/account.conf. Das folgende Beispiel zeigt den inhalt der datei, wenn ein share-online.biz premium account hinzugefügt werden soll

ShareonlineBiz:

username:password

geht dabei sicher, dass Ihr das Passowrt ohne abschließendes Leerzeichen in die Zeile eintragt.

Installation unter Ubuntu

Prüfen, ob pytho installiert ist

which python

Als ertes müssen wir sicher gehen, dass python installiert ist

apt-get install python

#bzw.

aptitude install python

dann müssene wir noch einige weitere Pakete installieren

apt-get install python-crypto python-pycurl python-imgaing python-beaker python-qt4 tesseract-ocr tesseract-rc-eng gocr unrar gcc g++ binutils make python-gmpy unzip m4 python-pygccxml gccgo lib32gcc1 lib64ggc1 libgcc-4.7-dev python-dev libcurl-dev libcurl-ocaml libcurl-ocaml-dev lubcurl3 libcurll3-dev libcurl13-gnutls

Jeztt installieren wir pyload selber. Wir müssen folgende Pakete downloaden

w3m http://get.pyload.org/get/ubuntu

Wir downloaden das paket über den Link und installieren über

sudo dpkg -i pyload-clix-x-x-.deb

Das Paket wird in der egel extrahiert nach /usr/share/pyload

Jetzt installieren wir die MPIR bibliothek

wget http://mpir.org/mpir-2.7.0-alpha12.zip

unzip mpir-2.7.0-alphas12.zip

cd mpir-2.7.0/

sudo ./configure

sudo make

sudo make test

sudo checkinstall

sudo make install

dann laden wir uns pycrypto

w3m https://www.dlitz.net/software/pycrypto/

#download über link, auspacken über

tar -xvzf pycrypto-2.6.1

cd pycrypto-2.6.1/

./configure

sudo python ./setup.py build

und dann laden wir uns pycurl

wget http://pycurl.sourceforge.net/download/pycurl-7.19.5.1.tar.gz

tar -xvzf pyuclr.tar.gz

cd pycurl-x.x.x.x/

python setup.py build

jetzt laden wir uns tesseract

sudo apt-get install autoconf automake libtool

sudo apt-get install libpng12-dev libpng12 libpng12-0-dev libpng-dev

sudo apt-get install libjpeg62-dev libjpeg62 libjpeg-dev

sudo apt-get install libtiff4-dev libtiff-dev python-libtiff libtiff4

sudo apt-get install zlib1g-dev

sudo apt-get install libleptonica-dev

wget https://tesseract-ocr.googlecode.com/files/tesseract-3.01.tar.gz

tar -xvzf tesseract-3.01.tar.gz

cd tesseract-3.01/

./autogen.sh

#falls ihr bei autogen einen fehler mit einem fehlenden m4-verzeihcnis bekommt, einfach anlegen über

mkdir ./m4

#

./configure

make

sudo make install

sudo ldconfig

und zum Schluss pyqt4

wget http://sourceforge.net/projects/pyqt/files/PyQt4/PyQt-4.11.3/PyQt-x11-gpl-4.11.3.tar.gz

tar -xvzf PyQt-x-x-x.tar.gz

sudo aptitude install python-sip python-sip-dev sip-dev

wget http://sourceforge.net/projects/pyqt/files/sip/sip-4.16.7/sip-4.16.7.tar.gz

tar -xvzf sip-4.16.7.tar.gz

cd sip-4.16.7/

python configure py.

make

sudo make install

cd PyQT-4.11.3/

sudo aptitude install mingw32

python configure.py -q /usr/bin/qmake-qt4



# checken der Verison mit

sip -V

sudo aptitude install libqt4-dev

Jetzt richten wir openssl für eine verschlüsselte Verbindung ein

sudo aptitude install openssl

cd ~/.pyLoad

openssl genrsa 1024 > ssl.key

openssl req -new -key ssl.key -out ssl.csr

openssl req -days 36500 -x509 -key ssl.key -in ssl.csr > ssl.crt

sudo aptitude install rhino

python ./pyLoadCore.py

service pyload restart

ln -s /etc/init.d/pyload /etc/rc2.d/S99pyload

nun tragen wir unsere Premium-Accounts unter /usr/share/pyload/accounts.counf ein, beispielsweise

ShareOnlineBiz:

<UserID>:<Passwort>

UploadedNet:

<UserID>:<Passwort>

Bevor wir pyLoad dauerhaft in Betrieb nehmen können, müssen wir ein paar Einstellungen festlegen. Das machen wir über

cd /usr/share/pyload

python ./pyLoadCore.py

und wir starten pyload zum ersten mal über

/etc/init.d/pyload start

Abschließende Nacharbeiten

Zusätzlich solltet Ihr testen, ob wie Weboberfläche von pyload funktioniert. Der standardport ist 8000. Unter http://dyndns.tld:8000 solltet ihr die oberfläche also öffnen können. Wenn ihr die oberfläche ach von außen erreichen können wollt, müsst ihr in der konfiguration eine listen-adresse von 0.0.0.0 eingestellt haben und für den port 8000 in Ihrem Router eine Portweiterleitung an die disktation eingerichtet haben.

Nun müssen wir noch konfigurieren, dass wir überi unseren Desktop-Browser Downloads zu pyLoad hinzufügen können. im folgendne Beispiel konfigurieren wir dazu FlashGot! f+ür den Firefox. Dann müssen wir in der Weboerbläche von PyLoad das ClickAndLoad-Plugin aktivieren. Dazu gehen wir im Menü auf den Reiter Plugins / Menu und aktivieren dort das clickAndLoad Plugin.

im danachaufpoppenden Reieter ClickAndLoad aktiiverne wir nochexternal link adding.

Ab jetzt passiert Folgendes: PyLoad lauscht auf dem Port 9666 nach Anfragen für das hinzufügen von Downloads. Über diesen Port ist es also mitHilfe des clikcandLoad-Plugins möglich, Links hinzuzufügen.

Wir konfigurieren jetzt flashGot! dazu, dass er für unser pyload auf der Adressse der NAS und den Port 9666 Links hinzufügt. Dazu gehen wir im Firefox auf Tools – FlashGot – More Options. Als Download Manager wählen wir pyload und geben die Adresse unserer NAS ein.

Wenn wir nun in Zukunft auf einen Link rechtsklicken könne wir im KOntextmenü FlashGot Link wählen und ihn somit zu pyload hinzufüpgen. Wenn wir mehrere Links ausgewählt haben, können wir ide option FlashGot All wählen.

Wir können acuh Links über die Weboberfläche mit dem Hinzufügen-Button adden. Wir können dann entweder einen Link hinzufügen oder eine .dlc-Datei hochladen. Dort können wir auch ein Passwort für zu entpackende .rar-Dateien festlegen.

Troubleshooting

Update 15.06.2015. Wenn pyLoad seit neuestem bei ihnen nicht mehr startet, löschen Sie im Home-Verzeichnis des Benutzers, unter dem pyLoad läuft, im Ordner ~/.pyload/userplugins/hooks die Datei HighWayMe.py und starten Sie pyload daraufhin neu. Danach wird die Datei neu heruntergeladen und pyLoad sollte wieder laufen.

Serveradministration Windows

Limits beim VServer ausgereizt – guter Rat ist teuer

27. November 2014 DaFRK Hinterlasse einen Kommentar

Wenn Sie die Limits bei Ihrem Vserver ausgereizt haben, ist guter Rat teuer. Denn in der Regel können Sie dann keine Befehle mehr über SSH auf der Shell ausführen. Das anfertigen von Backups – und sogar das Neustarten des Servers – wird hier zur Kunst.

Ihre Limits können sie mit dem Kommando

cat /proc/user_beancounters

prüfen. Ist bei einem der hier aufgezeigten Werte der maxheld- wert nahe dem zugehörigen barrier oder limit, liegt die Vermutung nahe, dass Sie Performance-Probleme gekommen. Wenn der Wert failcnt sogar einen Wert größer null hat, ist es sogar sehr wahrscheinlich.

die Probleme äußern sich dann vielschichtig. Bei Webanwendungen bekommen Sie öfters einen Error 500, und die Kommandozeile spuckt fehlermeldungen wie bash: fork: cannot allocate memory, failed to fork oder Ähnliches aus.

Der erste Schritt ist immer eine E-Mail an den Support Ihres Anbieters. Eventuell erkennt er das Problem und erhöht Ihre Limits, sodass Sie wieder Luft nach oben haben. DAs setzt allerdings ein sehr kulantes Verhalten des Providers voraus, da er Ihnen damit erlaubt, mehr Ressourcen mit IHrem Vserver zu verbrauchen, als Ihnen ursprünglich zustehen.

Wenn Sie jetzt noch schnell ein Backup ausführen wollen – oder Ihren VServer vielleicht sogar retten wollen, weil Sie sich vor einer Neuinstallation scheuen, müssen Sie zusehen, dass Sie diese Limits nicht erreichen.

Als erstes sollten Sie versuchen, über die Administrationsoberfläche Ihres Kundenlogins einen Neustart zu veranlassen, vielleicht behebt das die Probleme und Sie können wieder Befehle in der shell ausführen und somit verhindern, dass die Limits in Zukunft erreicht werden.

Meistens hilft es, in der Administrationsoberfläche des VServers den Rettungsmodus zu aktivieren. Jeder gute V-Server-Provider bieten ein solches Rettungssystem an, in welches Sie Ihren V-SErver booten können. Jetzt sollten Sie verhindern, dass beim Start des Servers bestimmte Dienste hochkommen, die viele Ressourcen fressen. Am sichersten machen Sie das, indem Sie dem Start-Skritp oder dem Binary des Dienstes ein chmod von 000 geben. Dienste, die dafür bekannt sind, Ihre Limits zu sprengen, sind der Apache Webserver oder das Parallels Plesk Panel. Letzters finden sie meist unter /etc/init.d/psa. Geben Sie dem Startskript ein chmod von 000 und veranlassen sie nun per Weboberfläche einen neustart des Servers. Eventuell haben Sie jetzt nach dem REboot die nötigen Ressourcen, um die nötigen Schritte durchzuführen.

Sobald Sie Ihren Server einmal so weit haben, dass Sie ihn wieder kontrollieren können, müssen sie in Zukunft dafür sorgen, dass Sie die Limits nicht mehr erreichen. Das können Sie beispielsweise tun, indem Sie bestimmte Dienste komplett ausschalten oder beispielsweise einigeKomponenten im Paralllels Plesk Panel deaktiverne – beispielsweise Anti-Spam-Schutz, Antivirenschutz oder Dr. Web. Das geht natürlich oft zu Lasten der Sicherheit, die sie anderweitig ausgleichen müssen.

Sollten Sie selbst mit diesen Maßnahmen Ihren Server nicht dazu kriegen, künftig die Limits nicht mehr zu sprengen, müssen Sie über ein Upgrade zu einem besseren Paket mit höheren Limits oder gleich über einen dedizierten Root-Server nachdenken – bei einem Root-Server können Sie die Limits in der Regel selbst kontrollieren und bis zur vollen Systemauslastung ausreizen. Eventuell bietet sich auch eine dedizierte Managed Server Variante an – im Fall von Webseiten also ein Webspace – im Falle von Gameservern ein Managed Gameserver, den Sie nur noch über eine Weboberfläche betreuen.

SAP

SAP Basis Wissen: Logische Systeme umsetzen mit BDLS

6. November 2014 DaFRK Hinterlasse einen Kommentar

Manchmal ist es notwendig, den Namen eines logischen Systems zu ändern. In unserem Beispiel wollen wir das logische System ID2CLNT810 in das logische System T90CLNT810 umziehen. Das geht in der Transkation BDLS.

2014-11-06_14h25_32

Als erstes machen wir einen TEstlauf. Deswegen bleibt der Haken drin. Gehen wir auf Ausführen, erhalten wir das Ergebnis des Testlaufs. Wenn wir zufrieden sind, können wir zurück gehen und den Haken rausmachen.

Wenn wir den Haken bei Testlauf aus machen und links oben auf Ausführen gehen, wird die Aktion final durchgeführt.

Wichtig dabei ist, dass man bestehende RFC-Verbindungen und User, die diesem logischen System zugewiesen wurden, auf Konsistenz hin überprüft. Die RFC-Destinations müssen auf jeden Fall umbenannt werden, so dass sich ihr Name mit denen des neuen logischen Systems deckt.

SAP

SAP-Wissen: Client in bestehende CUA / ZBV aufnehmen

4. November 2014 DaFRK Hinterlasse einen Kommentar

Ich bin derzeit auf der Suche nach einer neuen Arbeitsstelle in einer SAP-Beratungsfirma. Wenn Ihnen dieser Beitrag trotz der Hastigkeit seiner Erstellung gefällt und Sie in einer führenden Position sind – scheuen Sie sich nicht, mich zu kontaktieren 😉

Was ist eine ZBV / CUA und wie funktioniert sie?

CUA steht für Central User Administration, ZBV für Zentrale Benutzerverwaltung. Beide kürzel bedeuten also das selbe. mit einer CUA ist es möglich, in einem einzigen System die Benutzerstammdaten einer gesamten Systemlandschaft ( also mit mehreren Hosts, auf denen verschiedene SAP-Lösungen betrieben werden) zu verwalten. Dies sorgt für eine einfachere Verwaltung, ein einfacheres Backup, bessere Aufallsicherheit und Portbierbarkeit eines Systems sowie für eine generell einfacher gehaltene Administration. Änderungen in einer CUA werden automatisch auf alle im System angebundenen Child Nodes weitergereicht, so dass diese davon unterrichtet werden und Änderungen an Usereinstellungen somit sofort mitkriegen.

Zum Verteilen dieser Einstellungen wird eine funktionierende ALE (application Link Enablin) Landschaft voraugsesetzt. Diese hält die Daten konsistent und kümmert isch auch um die Regelung des Datenverkehrs. Eine ALE Systemgruppe wird von der CUA genutzt um Userdaten zwischen dem Zentralsystem und seinen Kind- oder auch Satellitensystemen über das ALE zu teilen. Deswegen macht es sinn, sich zuerst mit grundlegenden Informationen über ALE Integration Technology zu informieren. Dabei werden die Daten asynchron zwischen den Anwendungssystemen innerhalb der CUA-Landschaft ausgetauscht. Dadurch ist sichergestellt, dass ein Zielsystem auch dann noch die nötigen informationen bekommt, wenn es bei der Erstverteilung nicht erreichbar war.

Eines der Systeme in der CUA-Landschaft wird als sogenanntes Zentralsystem definiert. Das ist meist ein System, auf dem der SAP Solution Manager läuft. Das Zentralsystem wird dann mit jedem einzelnen Satellitensystem verbunden. Die Satellitensysteme sind nicht untereinander verbunden. Das Zentralsystem selbst enthält ein eigenes Kindsystem, das sich ebenfalls Daten aus der CUA holt. So pflegen sich die User des auf dem Zentralsystem installierten SolMan beispielswiese über die CUA. Als Zentralsystem sollte immer das System mit dem neuesten Kernel und Support Package Stack verwendet werden.

Eine Dokumentation über CUA Administration bekommt Ihr in der SAP Library im Pfad SAP NetWeaver / Security / Identity Mangement / Users and Roles / Central User Administration.

wir gehen von folgendem Szenario aus:

Ihr habt einen Client / einen mandanten in einem SAP ERP 6 / ECC System und wollt diesen in eine bestehende CUA / ZBV aufnehmen, die auf einem Solutin Manager System läuft. in unserem Beispiel ist das Kindsystem ein SAP ERP 6 IDES System mit der SID ID2 und dem mandanten 810.
in unserem Beispiel läuft die CUA-ADministration auf Mandant 900 des Solution Managers mit SID SM1 und wir wollen den Mandanten 810 eines SAP ERP 6 IDES-Systems SID ID2 anbinden.

Eine Central User Administration aufsetzen

Um eien CUA aufzusetzen, muss man die folgenden Schritte durchführen

Erstellen eines Administrators
Die Mandanten in den Systemen erstellen
Die Logischen Systeme spezifieren
Die Logischen Systeme zu einem Mandanten zuweisen
Die Systemuser erstellen
Die RFC Destinations erstellen
Die CUA selbst erstellen
Distribution Paramter für die Felder einstellen
Die Firmenadresse synchronisieren
die User transferieren

Erstellen eines Administrators

In einem klomplett neune System muss man erst einen Administrationsuser erstellen, mit dem wir später einige Schritte, wie beispielswiese das Definieren logischer Systeme, durchführen können. Standardnutzer wie DDIC oder SAP* sind dafür nicht vorgesehen, weil sie zu den Display-Usern gehören. einen solchen alternativen Administrationsbenutzer brauchen wir sowohl auf dem Zentralsystem, welches das CUA verwaltet, als auch auf dem Kindsystem, welches wir an das CUA anbinden wollen. in der Regel ist das aber gängig, weil sich normalerweise jeder SAP-Administrator einen extra Account mit seinen Credentials erstellt. Aber bei einigen Unternehmen nimmt man immer nur die Standarduser SAP* und DDIC her, was in diesem Fall nicht funktionieren würde und aus Sicherheitsgründen auch nicht zu empfehlen ist.

dazu loggen wir uns auf dem künftigen CUA als User SAP* mit dem Standardpasswort PASS ein.

wir wählen dann Tools / Administration / User Maintenance / Users (oder Transaktion SU01) und erstellen einen User und geben ihm für das System selbst das Profil SAP_ALL. in unserem Beispiel ist das der user DDIC_CP, den wir aus einer kopie des users DDIC erstellt haben. Dieser muss im Reiter Logon Data im Feld User Type den Typ Dialog eingestellt haben.

2014-11-05_15h17_18

Jetzt braucht der neue Administrationsbenutzer auf dem Zentralsystem für das logische System dieses Mandanten das Profil SAP_ALL und der neue Administrationsbenutzer auf dem Kindsystem für das logische System seines Mandanten ebenfalls das Profil SAP_ALL. normalerweise existiert für das eigene System bereits ein logisches System im Format <SID>CLNT<Mandant>, so dass wir in der Transaktion SU01 nur den Reiter Profiles aufrufen müssen und dem User das Profil zuweisen müssen. 2014-11-05_15h19_58

Falls es das logische System noch nicht gibt, erfahrt ihr weiter unten in dem Kapitel „Erstellen der logischen Systeme“. Das müsst Ihr aber dann mit dem User SAP* machen, da euer neuer Administrationsbenutzer ja noch keine Rechte hat.

Danach sollten wir noch den User SAP* gegen unberechtigten Zugriff schützen. Das ist in diesem SAP Artikel beschrieben.

Erstellen der benötigten Systems User

Um einen mandanten mit einer CUA / ZBV zu verbinden, braucht ihr auf beiden Systemen entsprechende User unabhängig von dem gerade erstellten Administratiosnnutzer.

in dem CUA-Mandanten auf dem Solution manager braucht ihr einen User, der für die anfrage von Satellitensystemen an das CUA nötig ist.
wenn ihr mehrere CUA’s miteinander vernetzt, braucht ihr auf dem CUA-System außerdem einen User für die kommunikation von CUA zu CUA.
Auf dem Satellitensystem / CUA-Client braucht ihr einen User für die Anbindung zur CUA.

Alle diese User brauchen das Profil SAP_ALL.

Was sind Systembenutzer (system users)

System users werden auch CPIC User in älteren Versionen genannt und werden für die interne kommunikation der Systeme in einer ALE Gruppe benötigt, um Daten über das ALE-System zu verteilen. Diese Systembenutezr werden in den Zielsystemen definiert (also in den Satellitensystemen, die die Daten bekommen sollen) und werden danach wiederum in den RFC Destinations der satellitensysteme eingetragen. Um die Sicherheit der Systemlandschaft zu erhöhen, sollte man nur Systembenutzer mit hohen sicherheitseinschränkungen erstellen, kombiniert mit einer speziellen Rolle für System User.

Prinzipiell wäre eine USER ID ausreichend und könnt für alle Systembenutzer genutzt werden.Es ist aber praktischer, für jede RFC Destination einen extra Systemuser zu haben, da man diesen Nutzer für die jeweilige RFC Verbindung dann extra pflegen kann (Passwort ändern usw). Es sollte also genau so viele Systembenutzer wie RFC Destinations in unserem System geben. Für Systembenutzer werden deshalb auch keine Lizenzaufschläge berechnet.

Um die Verwaltung der Systembenutzer zu vereinfachen, sollte man sich an folgende Konvention zur Namensvergabe halten:

im Zentralsystem wählen wir die Konvention CUA_<System ID>. Dieser System User werden in den RFC Destinations der Satellitensysteme – von eben diesem zum Zentralsystem – genutzt
in den anderen SAtellitensdystemen ist die Namenskonvention CUA_<System ID>_<Client>. Diese Systembenutzer werden im Zentralsystem in den RFC Destinations – vom Zentralsystem zum Satellitensystem – genutzt.

zuerst erstellen wir den User CUA_SM1 auf unserem Zentralsystem SM1. dieser nutzer wird in allen logischen Systemen des Zentralsystems als Systembenutzer verwendet.

wir erstellen eien Sytemuser CUA_<System ID>_<Client> in jedem Satellitensystem für jede RFC Connection vom Zentralsystem zum Kindsystem. wir erstellen also auf ID2 im mandant 810 einen User CUA_ID2_810 mit unserem neuen Administrationsuser aus dem ersten Schritt oder mit SAP*, vergeben dort grundlegende infmrationen zur Adrese, ein Initialpasswort und einen User Type Communication. Dieser Typ hat den Vorteil, dass sich dieser User ab sofort nicht mehr in eine Menüführung einloggen kann, sondern ausschließlich für die RFc-Verbindung genutzt wird. Man kann ihn also nicht mehr so leicht über beispielsweise falsche Passworteingaben im Logon-Bildschirm sperren.

2014-11-05_15h45_16

sowie ein Profil SAP_ALL. Dazu gehen wir unter Profile auf eine neue Zeile und gehen auf die Papiere, um eine übersicht der Profile zu laden

2014-11-05_16h11_37

Das Profil SAP_ALL befindet sich in dieser Liste im Reiter „Sammelprofile“ oder „composite Profiles“

2014-11-05_16h12_36

Im Zentralsystem fügen wir unserem CUA_SM1 jetzt die Rollen SAP_BC_USR_CUA_SETUP_CENTRAL und SAP_BC_USR_CUA_CENTRAL.

In allen anderen logischen SYtemen erstellen wir jeweils einen Systembenutezr mti den Rollen SAP_BC_USR_CUA_SETUP_CLIENT und SAP_BC_USR_CUA_CLIENT.

diese Rollen entahtlen keine menüeinträge, sondern nur Authentifzierungsdaten, da sihc die Systembenutzer nicht im Dialogmodus einloggen können. einige Felder für die authorisationsdaten enthalten einen ASterisk (*) weil das System eventuell komplette Authorisierung für für Teile des Systems braucht. Die Rollen weißen wir in der Transaktion Profile Generator (PFCG) zu. Die oben genantnen Standard-Rollen kopieren wir in den Customer namespace der jeweiligen System User.. die SETUP-Rollen rbauchen wir nur während des Setups der CUA.

Da sErstellen geht folgendermaßen vonstatten:

Wir loggen uns in das Zentralsystem als ein Administrationsnutzer und wählen die Transkaation SU01. Wir erstellen den user CUA_ADM der vom Zentralsystem für den User Transfer SCUG genutzt wird und die mehreren System Users für die RFC Destinations ide wir in den kindsysteemen erstellen. Allen System usern geben wir ein initialpasswort und edn user Typ communication. Wir weißen den Systemusern auf dem Zentralsystem für die Kindsyteme und ddem System User CUA_ADm die rollen Z_SAP_BC_USR_CUA_SETP_CENTRAL und Z_SAP_BC_USR_CUA_CENTRAL zu. Dcen Usern für das Zentralsystem auf den Kindsystemen weißen wir die Rollen Z_SAP_BC_USR_CUA_SETP_CLIENT und Z_SAP_BC_USR_CUA_CLIENT zu.

User erstellen könnt ihr mit der Transaktion SC01. Erstellt den User entweder von hand oder kopiert ihn au einem Standardnutzer wie DDIC und passt danach bestimte einstellungen an. Der User muss beispielsweise den Typ „dialogbenutzer“ haben und braucht eben das entsprechende Profil SAP_ALL.

Erstellen des anzubindenden Mandanten

In der Regel habt ihr den Mandanten, den Ihr anbinden wollt, bereits erstellt. Prüfen könnt ihr das mit der Transaktion SCC4 auf dem anzubindenden System. Ein anzubindendes System wird auch CUA-Client oder Satellitensystem (sattelite system) genannt. Die Transaktion zeigt alle existierenden mandatne. Wenn der mandant noch nicht erstellt ist, könnt ihr das natürlich machen. Einen mandaten kann man grundsätzlich von vorne erstellen mit einem leeren Template als Basis. Drückt dazu auf das Stift/Brille-Icon, um den Änderungmodus in SCC4 zua ktivieren und macht in einer neuen Zeile einen neuen Eintrag mit der mandantennummer, die ihr haben wollt. Man kann einen neuen mandanten aber auch über Mandantenexport und anschließenden -import erstellen.

Erstellen der logischen Systeme

Mandanten, die von der ZBV verwaltet werden, werden im System als logische Systeme angesprochen. Deshalb muss erstmal auf dem anzubindenen System ein logisches System angelegt und anschließend einem bestehenden Mandanten auf dem anzubindenden System zugewiesen werden. Wir brauchen afu dem Zentralsystem ein logisches System für jedes CUA-System, also für das Zentralsystem selbst und alle daran angebundenen Klienten. Und auf dem jeweiligen Kind-System brauchen wir ein logisches System für das Zentralsystem sowie für das Satellitensystem selbst. Das Anlegen geht dort in der Transaktion SCC4. Wir können erstmal prüfen, ob dafür schon ein logishces System besteht. Einfach den amndanten markieren und auf das Lupe-Symbol (details). dann seht ihr in der spalte Logisches System, ob es daüfr bereits ein System gibt.

Logische Systeme haben bestenfalls die folgende namenskonvention: <SystemID>CLNT<Mandant>.

wir müssen nun also auf dem Kindsystem prüfen, ob es bereits ein Logisches System für das Kindsystem selbst gibt (ID2CLNT810) und für das Zentralsystem (SM1CLNT900).

in unserem Beispiel würde man in der Liste z. b. so den Eintrag für SM1 finden:

2014-11-05_14h24_15

und jetzt schauen wir auf dem Zentralsystem nach, ob es dort bereits ein Logisches System für sich selbst (SM1CLNT900) und für das Kindsystem gibt (ID2CLNT810). in unserem Beispiel gibt esin logisches System für SM1CLNT900, aber noch keines für ID2CLNT810

gibt es noch kein logisches System, geht auf im Feld Logisches System auf die ikone mit den zwei Papieren, um eine übersicht der bestehenden Logischen Systeme aufzuzeigen.

2014-10-31_16h39_33

Geht nun auf das Ikon mit dem Papier – Create Values – und überspringt den Schritt, in dem ihr ein projekt angeben sollt.

Daruafhin öffnet sich ein Fenster mit IMG Activities.

wählt dort Set Up Logical Systems

2014-10-31_16h45_07

Nun wählt Ihr Define Logical System und geht auf Execute

2014-10-31_17h02_33

Klick tide warnung weg, dass diese Aktion mandatenunabhängig ist.

2014-10-31_17h03_33

Ihr habt wieder eine Übersicht der logischen Systeme, könnt aber nun den Button New Entries anklicken

2014-10-31_17h04_20

Nun könnt ihr ein neues logisches System anlegen. Damit das geht, müssen die bisherigen Einträge für die logischen Systeme alle voraussetzungen erfüllen. War Ein Kollege hier unachtsam, reagioert das System an dieser Stelle mit einer Fehlermeldung „Please fill in all required fields“. Das Sytem will einfach, dass Sie zu jedem System einen Namen hinzufügen. Machen Sie das, und probieren Sie es erneut, dann müssten Sie ein Fenster bekommen, mit dem Sie ein neues Logisches System definieren können. Einige User wie DDIC beispielsweise sind aber beispielsweise nicht dazu vorgesehen, in Kundensystemen Änderungen vorzunehmen.

2014-11-05_14h28_57

In diesem Fall habt ihr den ersten Schritt nicht wirklich befolgt: Ihr solltet im ersten Schritt einen Administrationsnutzer erstellen, der eben diese Änderungen durchführen kann.

Nun definieren wir das logische System im neuen Fenster und gehen im Anschluss auf die Diskette zum Speichern

2014-11-05_15h15_25

die ghleiche Prüfung müssen wir auf dem Solution Manager wiederholen – gibt es zu dem CUA bereits ein logisches System und für den SM1 selbst ebenfalls schon eines?

Falls es ein logishces System bereits geht, darf man eventuell nicht außer Acht lassen, dass es vielleciht besser ist, das alte logische System zu löschen

Alternative: Das logische System direkt ohne Umwege erstellen über die Transaktion SALE / BD54

Anstatt über die Transaktion SCC4 können wir das Logishe System ohne vorherige Prüfung auch direkt über die Transaktion SALE erstellen. dort wählen wir dannIdoc Interface / Application Link Enabling (ALE) / Basic Settings / Logical Systems / Define Logical System (Transaktion BD54). Alternativ dazu wiederum können wir die Tabellensicht V_TBDLS pflegen mit der Transaktion SM30.

Dort wählen wir dann Edit / New Entries. In der spalte LogSystem erstellen wir einen neuen logical name in Großbuchstaben.

Für die Vergabe eines Logical Names für ein logisches System empfiehlt sich folgende Konvention: <System ID>CLNT<Mandant>.

Nun haben wir ein logisches System erstellt, es ist aber dem Mandanten noch nicht zugeweisen. Man kann einen mandanten auch nur zu einem einzigen logischen System hinzufügen. Das müssen wir aber nur für die logischen Systeme machen, die das eigene System ansprechen – sprich das Kindsystem Id2 muss seinen eigenen mandanten 810 mit dem logischen System ID2CLNT810 verbinden und das Zentralsystem seinen eigenen M Mandanten 900 mit dem logischen System SM1CLNT900. In den meisten Fällen ist das bereits geschehen. Falls nicht, verbinden wir beide logische Systeme, fall snoch nicht geschehen, mit den entsprechenden Mandanten. Das geht in der Transaktion SCC4 wieder im Fenster Display IMG (steht für Display Implementation Guide), dort liegt direkt unterhalb der eben genutzten tabelle Define Logical System die Tabelle Assign Logical System to Client

2014-10-31_17h08_25

Geht ihr hier auf execute, bkeommt ihr wieder eine Warnung, dass die Tabelle cross-client ist (wegklicken). Dann erhaltet ihr eine Tabelle mit Zuordnungen von Clients zu logischen Systemen. hier könnt Ihr einen entsprechenden Eintrag tätigen. nun ist das logishce System mit dem Mandanten des Systems verbunden. Macht das bitte auf beiden Systemen.

wir müssen natürlich jedem Mandanten / Klienten, der in die CUA aufgenommen werden soll, ein logisches System zuweisen.

Hier im Bild zu sehen: der mandantn 900 zeigt uns in seinen Details, dass er mit dem Logischen System SM1CLNT900 verbunden ist, wunderbar.

2014-11-05_15h26_33

Erstellen der RFC Destinations

Dazu loggen wir uns auf dem zentralsystem (SM1) ein. im implemenmtation Guide (Transaktion SALE) wählen wir Sending and Receiving Systems – Systems in Network – Define Target systems for RFC Calls (Transaktion SM59)

das Sytsem zeigt den Bildschirm Display and Configuration of RFC Connections.

2014-11-05_17h32_54

Wir erweitern die Sicht ABAP Connections und suchen nach der RFCC Destination mit dem namen des Sattelitensystems, in unserem Fall ID2CLNT810

Wenn das Satellitensystem nicht in der Liste ist, müssen wir diese RFC Destination erstellen. Der RFC Destinaion geben wir den selben namen wie dem logischen System (ID2CLNT810) und geben den namen in Großbuchstaben ein. Als Verbindungstyp kommt 3 ein. Diese Zahl steht für eine Verbindung zu einem ABAP System – was richtig ist, weil wir uns auf den ABAP-Stack des ERP IDES-Systems auf ID2 verbinden wollen.

2014-11-05_17h36_33

Wenn das Kindsystem in der Liste ist, müssen wir den Namen des existierenden Systembenutzers herausfinden. Dazu wählen wir das Satellitensystem und wählen Edit / change. Das System zeigt jetzt RFC Destination <logical system name>. Der Systemuser des Satelittensystems ist im Logon & Security Reiter im Feld User hinterlegt.

Ansonsten, wenn die RFC Destination noch nicht angelegt war, legen wir die Informationen nun im Reiter Logon & Security selbst an. Dort kommt unter Client der Mandant des anzubindenden Kindsystems (810) rein. Unter User schreiben wir den auf diesem Kindsystem zu diesem Zweck erstellten User rein (CUA_ID2_800)

2014-11-05_17h44_00

Im Reiter TEchnical Settings müssen wir jetzt noch im Feld Target Host den Hostname des Zielsystems (id2.yourdomain.com) und unter System Number die Instanznummer (hier im Beispiel 00) des Systems eingeben.

2014-11-05_17h53_35

Jetzt haben wir gerade eine RFC Destination von SM1 nach ID2 angelegt. das selbe machen wir jetzt auf dem Kindsystem ID2, um eine Verbindung von ID2 nach SM1 herzustellen.

Die Central User Administration selbst erstellen (falls noch nicht vorahnden)

Voraussetzung ist, dass die logischen Systeme, System User und RFC Destinations bereits definiert sind. Sollten wir bereits die CUA erstellt haben und nur noch die Kindsysteme neu einbinden wollen, können wir den Report RSDELCUA mit der Option Reorganize CUA Tables im Zentralsystem und den relevanten Kindsystemen ausführen. Dadurch löschen wir alle DAten der früheren CUA über die Kindsysteme und stellen sicher dass es keine Inkonsistenzen gibt wenn wir die Kindsysteme neu einbinden.

Wir loggen uns in das Zentralsystem ein und öffnen wieder die Transaktion SALE. wir wählen Modeling and Implementing Business Processes / Predefined ALE Business Processes / Corss-Application business Processses / Central user Administration / Select Model View für Centrla Administration (transaktion SCUA).

Logische Systeme in CUA einbinden

Das geht wieder über die Transkation CUA

2014-11-05_17h58_55

Im Hauptbildschirm von SCUA einfach auf den Stift (edit) gehen und im daruaffolgendne Fenster in einer neuen Zeile das Logische System auswählen (ID2CLNT810)

2014-11-05_18h00_28

Wenn wir jetzt auf Save selected Systems gehen, müsste das systme dort auftauchen. wir bekommen wenig später automatisch die Display Logs angezeigt.

2014-11-05_18h05_23

Normalerweise sieht man in disem Display Blog dann Einträge wie:

ALE distirbution Model saved
Central ujser ADministration was acitvated
Text comparison saved

Folgendermaßen können wir prüfen, ob alles geklappt hat: Wir loggen uns auf dem Kindsystem (ID2) ein, öffnen Transaktion SALE und wählen Modeling and implementing Business Processes / Predefined ALE Business Processses / Cross-Application Business Processses / central user Administration / select model View for Central ADministration (Transaktion SCUA)

um zu prüfen dass das distribution model verteilt wurde, wählen wir Distribution Model / display strucutre oder gehen im Hauptbildschirm der Transaktion SCUA auf die Brille oder den Stift

2014-11-06_15h00_00

Wenn alles geklappt hat, müsten erstmal die eingebundenen Systeme mit grünen statusleuchten ausgestattet sein und in der Übersicht auftauchen. In dieser Übersicht tauchen auch veraltete logische Systeme auf, die wir noch aus früheren Konfigurationen in einer alten CUA drin haben können. Diese könennw ri markieren und mit einem Klick auf die Minus-Schaltfläche löschen. Eventuell geht das nicht, weil da eine Meldung kommt „Cannot delete: Target system <altes logisches System> is part of an active CUA“. in diesem Fall müsst ihr das logische System erst in der Transkation WE20 – Partner Profiles – Partner Type LS – <altes Logisches System> auswählen und mit KLick auf den papierkorb löschen. Dann müsst ihr in der Transaktion BD64 unter Central User Administration – <SID> Client <Mandant der CUA> ebenfalls den Eintrag für das logische System löschen – dazu wiederum müsst ihr in der baumarchitektur bis zum logischen System durchklicken und dann die Unterknoten, die Namen haben wie „User Copy“ etc. löschen. Wenn ihr nämlich auf das logische System selbst klickt und auf den appeirkorb geht, erhaltet ihr die meldung „Action cannot be carried out on target node“ – ihr müsst stattdessen alle Unterknoten löschen und dann auf Refresh – dann ist das System verschwunden.. Danach müsst ihr den Eintrag in der Transkation BD54 ebenfalls löschen. Dann müsst ihr in der Transaktion WE21 unter Ports / Transactional RFCs den Idoc-Record für das logische System finden. Dazu müsst ihr euch durch die Knoten mit Namen wie A000000XX klicken und den finden, dessen RFC Destination den Namen des altne logischen Sytems hat, und diesen dann löschen. wenn ihr dann das Logische System jetzt final in SCUA löschen könnt, könnt ihr es endgültig in der Transaktion SALE unter Define Logical Systems löschen. Damit ist es nun endgültig verschwunden.

Jetzt müssten wir desweiteren sehen,d ass wir keine User master Records in den Kindsystemen mehr erstlelen können (SU01). Wir können aber user verwlaten und löschen die bereit sauf dem Kindsystem existieren bevor wir es in die CUA integriert haben.

Wir können es auch so testen: wir loggen uns im Zentralsystem ein (SM1), gehen in die Transaktion SU01, erstellen einen Testuser mit irgendeinem beliebigen Namen. Wir geben ihk eine Adresse und ein intiialpasswort, wie bereits bekannt, und gehen dann in den Reiter Systems, um ihn als System das Kindsystem zuzuweisen.

2014-11-05_18h11_42

wenig später, nachdem wir mit dem Disketten-Symbol den Eintrag nun gespeichert haben, müssten wir uns auf ID2-810 mit idesem User und seinem Initialpasswort einloggen können. Wenn das der Fall ist, funktioniert die CUa-Distribution.

Field Distribution Parameter einstellen

Beim Einsatz einer CUa kann man Distribution Paramter in der Transkation SCUM nutzen um festzulegen welche indivuduellen Teile eines User master Records gefpelgt werden sollen:

im Zentralsystem
Lokal auf dem child Node (Local)
im child Note mit automatischer Verteilung zum Zentralsystem und den anderen CUA Kindsystemen

Jedes Eingabefeld in der User Maintenance transaktion SU01 hat ein Feldattribut, das wir einmla im Zentralsystem mit der Transkation SCUM während des customizens setzen können. So weit wie möglich sollten wir dann den Field Maintenance indikator danach nicht mehr ändern. Wenn wir eine Distribution von lokal auf global umstellen, werden beispielsweise Rolleneinstellungen des Kindsystems durch die CUa überschribeen.

Um die Einstellunge zu machen führen wir folgendes durch:

wir loggen uns auf dem ztentralsystem ein und gehen ind ie Transaktion SALE . Wir wählen Modeling and implementing Business Processses / Predefined ALE Business Processses / Cross-application Business Processes / Central user Administration / set Distirbution PArmeters for Fields (transkation SCUM).-

DAs System zeigt nun den Bildschirm User Disitrbution Field Selection, mit Reitern der Felder dessen Verteilungsparamter gesetzt werden kann. Um zusöätzliche Felder anzuzeigen, drückt man die Bild unten taste

Wir können nun die folgenden Einstellungen wählen

Global	Wir können die Daten ausschließlich in dem Zentralsystem pflegen. Die Daten werdne dann automatisch an das Kindsystem weitergegben. Diese Felder akzeptieren keine Eingaben im Kindsystem und können daher nur angezeigt werden. Alle anderne Felder die nicht auf „global“ gesetzt werden akzeptieren Eingaben sowohl im Zentral- als auch im Kindsystem und unterschieden sich nur durch eine unterschiedlcihe Verteilung der Änderungen
Proposal	Die Standardwerte im Zentralsystem werden autoamtisch an das kindsystem übertragen wenn ein user erstellt wird. Nach der verteilung klönnen die Daten NUR LOKAL verwlatet werden und werden danach nicht mehr verteilt wenn wir die Daten im Zentral- oder Kindsystem ändern
RetVal	Wir können die Daten sowohl zentral als auch lokal ändern. Nach jedem lokalen Ändern der Daten werden die Ämderngen an das Zentralsystem geschickt und von da aus zu a nderen Systemen
Everywhere	Wir könen die Daten sowohl zentral als auch lokal ändern. Aber die änderungen die im Zentralsystem gemacht werden werdne auch an andere Systeme weitergeleitet, während lokale Änderungen in den Kindsystemen nicht verteilt werden.

wir speichern unsere einstellungen

Interessant ist in diesem Zusammenhang noch der Reiter Locks

Diese Einstellujng bestimmt, ob man Sperren eines Users auch als lokaelr Administrator entfernen kann oder dies explizit im Zentralsystem machen muss.

es gibt hierbei verschiedene Einstellungen bezüglich der Sperreinträge für User, auf die ich hier nicht genauer eingehen werde.

Firmenadressen synchronisieren

DAs Zentralsystem muss jetzt informationen über alle gültigen Firmenadressen haben. diese werden dann an alle Kindsysteme verteilt so dass es einen konstitnetne status über die Firmenadressen in der gesamten CUA-LAndschaft gibt. So wird sichegrestellt, dass jeder systemübergreifende Firemandressschlüssel einzigartig ist und dass firmenadressen mit dem selben Namen, auhc die selbeVoraussetzung ist, dass bereits alle Firmenadressen in der Transaktion SUCOMP in der CUA-LAndschaft angelegt wurden.

Als erstes räumen wir alle Firmenadressen sämtlciher Systeme mit dem Report RSADRCK2 in Verbindung mit der SAP Note 439122 auf. Wenn Dateninkonsistenzen gefunden werden entfernen wir sie manuell.

Danach loggen wir usn in das Zentralsystem ein, gehen in die Transkation SALE und wählen Modeling and implementing / Predefine ALE BUsiness Processes / central user Administraiton / Transfer Users form new systems (Trtansaktion SCUG). Nun wird der bildschirm Central suer Administraiton STrucutre angezeigt.

Wir wählen den ersten Child Node den wir mit dem Zentralsystem snychorniseren wollen und wählen den Button iSynchronize Comapndy Adresses in the Central SYstemI. Es erscheint CUA: Synchronization of the Company Adresses, in welchem das SYtem eine Liste anzeigt in welcher die Firmenadressen der ausgewählten Kidnsystmeen mit dem Zentralsystem verlgichen werdne. Alle Firmenadresen die im Zentral- oder Kindsystem gehalten wurden, tauchen in dieser Liste auf. Wir gehen nun alle Unterlisten durch, welche jeweils die Adressen im Zentralsystem und in den Kindsystemen getrennt auflisten. Es gibt dabei folgende Kategorien

In Central Sstem Only	Diese Firmenadressen existieren nur im Zentralsystem. Wir können sie sofort verteilen indiem wir Distribute to Child System wählen oder das automatische Verteilen später erlauben
In Child System only	diese firmenadressen exisiteren nur in den child nodes, nicht im Zentralsystem. Wir haben foglende optionen. Wenn die Adresse korrekt ist und bentögit wird, könne wir sie dem zentralsystem hinzufügen indem wir die Firma des Kindsystems auswählen und dann auf Copy from Child System gehen. Wenn die Adresse hingegen inkorrekt ist oder nicht bneötigt wird, können wir sie im Kindsytem über die Transaktion SUCOMP löschen
Different Company Adresses	Diese Adressen existieren sowohl zentral als auch lokal auf einem Child Node und ahebn den selben firmen adress Schlüssel, unterschieden sich aber in den ersten beidne Feldern des Firmennamens. wir müssen daher den sytemübergreifenden Adressschlüssel auf konsistenz prüfen. Wenn die Daten inkonsistent sind, aber der adressschlüssel die selbe firma referenziert in ebiden systemen, müssen wir die daten synchronisieren, indem wir die Firma vom Zentralsystem wählen und Distirbute to Child Systems wählen oder sie automatisch verteilen lassen. Wenn Sie inkonsistent sind, aber zwei verschiedene Firmen nur den selben Company Adresss Key nutzen, löschen wir die inkonsistenz im kindsystem über die transkation SUCOMP.
Identical Company Adresses	diese Firmenadressen exisiteren zentral und lokal, und die ersten beiden Felder des Firmennamens sind identisch. Wir müssen die firmenadressdatan vergleichen und entweder Copy from Child System wählen, wenn die daten im kindsystema ktuelelr sind, oder Distribute to Child System wenn das im Zentralsystem aktueller ist. Wenn es in beiden Systemen unterschiedliche Felder gibt, die jeweils aktuelelr sind, müssen wir dies manuell synchronisieren
Company Adresses Already Synchornized	Dieses Resultat wird während der synchronisation angezeigt.

das wiederholen wir mit allen child nodes und wählen jeweils den synchronize company adresses button im zentralsystem. Nachdme wir alle korrekten und benötigtne firmenadressen in das zentralsystem snychornisiert haben, wählen wir Back um die adressverteilung im Zentralsystem zu starten. Im Zentralsystem wählen wir dann den Button Distirbute -Syncronized company adresses to Target Systems. Es erscheint der Schirm CUA: synchornization of the Comapyn Adresses

Wir wählen Distirbute to all child Systems. Ein Log erschient dass anzeigt ob die Vertileung egstrtet wurde.

Um das Resultat zu prüfen, wählenw ir Back und dann Synchornize Comapny Darresses in the Central Systems. Alle firmenadressen sind gelistet unter Company Adressesa already Synchonrized mit infomrationen über das Verteilungsresultat.

Usergruppen synchronisieren

damt wir die Möglcihekti haben User von einem Child Note und vom Zentralsystem zu kopieren oder um User vom Zentralsystem auf ein Child System zu kopieren, muss die User Gruppe die dem User zugewiesen ist in alleln Systemen sein, in die der User existiert.

Wir müssen die usergurppen, falls nocht icht vorhanden, auf jeden FAll erstlelen. Das geht über transaktion SUGR. Wir vergleichen die user gruppen der rlevanten systeme und stellen fest ob usergurppen feheln. dann erstellen wir die fehlendne gruppen im system amnuell.

Users aus neuen System transferien

Wenn man ein neues System in das Verteilungsmodell reinnimmt, müssen wir sichergehen dass die user master records im neuen system in das zentralsystem übertragen werden.

Voraussetzung: Die Firmenadressen wurden bereits synchornisiert.

Loggt euch in das Zentralsystem ein, geht in die Trnasaktion Sale, wählt Modeling and implementing Business processes / Predefined ALE Business Processes / central user Administration / Transfer Users from new Systems (transaktion SCUG).

Das sYstem ezigt dne schirm Central user Administraiton STrucutre display mit einer baumsturktur der Systeme im Verteilermodell. die systeme mit dem indikator New enthalten user master Records die noch nicht in der CUA drin sind.

Wir wählen alle user unter new und changed und wählen dann transfer users. Das wiedehrolen wir für alle child nodes von denen wir user transferien wolen. Nachdem der user transfer fertig ist, entfernenw rid ie rollen Z_SAP_BC_CUA_SETP_CENTRAL und Z_SAP_BC_USR_CUA_SETP_CLIENt von den system users. Diese Rollenw erdne nur gebraucht um eine CUa aufzusetzen, nicht zum Betreiben. mit der Transkation SCUl prüfen wir ob die Verteilung erfoglreich war.

SAP

Einfachere Anmeldung an SAP Logon mit Hilfe von SAPSHORTCUT

31. Oktober 2014 DaFRK Hinterlasse einen Kommentar

Viele kennen das Problem, dass es sehr mühsam ist, sich mit SAP Logon / SAP GUI auf multiplen ERP-Systemen anzumelden. Für jedes hat man bestenfalls noch ein anderes Passwort und verwechselt diese auch noch.

Eine einfache lösung für dieses Problem ist eine Verknüpfung auf die sapgui.exe, welche sich standardmäßig unter C:\Program Files (x86)\SAP\FrontEnd\SAPgui befindet. Mit dem Parameter /SHORTCUT kann man ab SAP Logon 6.20 das lästige Anmeldeprozedere verkürzen.

Einfachere Anmeldung an SAP Logon mit Hilfe von SAPSHORTCUT weiterlesen →

Serveradministration Linux

Public Key Authentication an Ubuntu OpenSSH mit Windows puTTY-Client

28. Oktober 2014 DaFRK 2 Kommentare

Wie funktioniert Public Key Authentication?

Anstatt eines Passwortes verifiziert der Server den Login eines Benuzters über Schlüsselpaare. Es gibt einen privaten Schlüssel und einen öffentlichen Schlüssel. Der öffentliche Schlüssel bleibt bei dem PC, von dem aus ihr euch auf den Server verbinden wollt. Es ist empfohlen, für jeden Rechner einen extra Schlüssel zu haben. Der öffentliche Schlüssel wird aus dem privaten Schlüssel erstellt und wird auf dem Server hinterlegt. der öffentliche Schlüssel ist im Klartext ersichtlich – es ist nicht schlimm, wenn den öffentlichen Schlüssel jemand in die Finger kriegt, denn der Client, also der Teil, der sich zum Server verbinden will, muss in seinen SSH-Client den privaten Schlüssel eingepflegt haben. Der öffentliche Schlüssel bringt einem Angreifer gar nichts, denn dieser Schlüssel liegt nur auf dem Server.

Wenn jetzt im Gegenzug jemand den privaten Schlüssel von euch klaut, dann kann er daraus aber ebenfalls nicht ohne weiteres etwas anfangen. Denn um diesen Schlüssel in seinen eigenen Client einspeisen zu können, muss er wiederum ein Passwort eingeben, mit welchem ihr zuvor euren privaten Schlüssel gesichert habt – der private Schlüssel ist nämlich im Gegensatz zum öffentlichen Schlüssel enkryptet und kann nur mit Hilfe des Passwortes entschlüsselt werden. Außerdem braucht er das Passwort, um einen öffentlichen Schlüssel zu generieren, was vielleicht nötig ist, wenn dieser noch nicht auf dem Server der Wahl hinterlegt ist.

Public Key Authentication an Ubuntu OpenSSH mit Windows puTTY-Client weiterlesen →