SAP Mandantenkopie – Größenbestimmung
Bei einem Kunden hatte ich den Auftrag eine Mandantenkopie zu erstellen. Auf der Suche nach einer Möglichkeit die Größe des Quellmandaten zu ermitteln bin ich über den Report RSSPACECHECK gestolpert.
Dieser frägt nur wenige Informationen ab und mit einer Gegenprüfung der Mandantennummer in der SCC4 kann schnell ermittelt werden welcher Mandant kopiert wird.
Die Frage nach den „Klassen“ der Tabellen können wir aus der DD07L Tabelle auslesen, hier gibt es unterschiedliche Tabellenattribute:
A Anwendungstab. (Stamm- und Bewegungsdaten)
C Customizingtabelle, Pflege nur durch Kunden, kein SAP Import
L Tabelle für Ablage temporärer Daten, wird leer ausgeliefert
G Customizingtabelle, gegen SAP UPD geschützt, nur INS erlaubt
E Steuerungstabelle, SAP und Kunde haben eigene Key-Bereiche
S Systemtabelle, Pflege nur durch SAP, Änderung = Modifikation
W Systemtabelle, Inhalt über eigene TR-Objekte transportierbar
Report RSSPCAECHECK:
Achtung: je nach Mandantengröße kann der Report sehr lange laufen
vSphere 6.7 – OVF Export
In einem Kundenprojekt bin ich aktuell darüber gestolpert das ein OVF Export einer vSphere 6.7 VM bei Import in einer vSphere 6.5 Infrastruktur zu Problemen führen kann.
Auch wenn die Hardware Version (Kompatibiltät) beachtet wurde kommt es beim importieren zu einer Fehlermeldung.
Bad response code (500) from POST request
Hierfür gibt es den VMware KB Artikel 67724 welcher einen Workarround beschreibt. Das OVF File muss nach dem exportieren der VM manuell angepasst werden. Alle Codezeilen it nachfolgendem Code müssen dabei entfernt werden. Anschließend klappt es auch mit dem Import
<File ovf:id="file3" ovf:href="<VM Name>.nvram" ovf:size="8684"/>
<vmw:ExtraConfig ovf:required="false" vmw:key="nvram" vmw:value="ovf:/file/file3"/>
MacOS: Dark Mode für einzelne Apps deaktivieren
Bei manchen Apps auf dem Mac fällt mir die Identifizierung oder Bedienung im Darkmode recht schwer. Nun bin ich über eine Möglichkeit gestolpert für einzelne Apps den DarkMode zu deaktivieren.
Beispiel für „spotify“:
defaults write com.spotify.client NSRequiresAquaSystemAppearance -bool yes
Falls ihr diesen String „com.spotify.client“ für eure Applikation nicht kennt könnt ihr diese mit folgendem Befehl in einem MacOS Temrinal herausfinden:
osascript -e 'id of app "Outlook"'
Fand ich ganz hilfreich, vielleicht kann das jemand anders auch noch brauchen.
SLES15 – Upgrade DVD erstellen
SLES15 kommt von Hause aus mit einer „minimalen“ Installations-DVD sowie einer zweiten Daten-DVD mit den unterschiedlichen Modulen welche man zusätzlich installieren kann. Diese Module umfassen z.b. SLES, SLED, or SLES for SAP usw.
Für ein lokale Upgrade ohne Internetverbindung gibt es jetzt aber kein einzelnes Medium mehr. Um einen Upgrade ohne SMT / SUSE Manager oder Proxyverbindung für ein einzelnes oder viele Systeme zusammen stellen zu können gibt es die folgende Anleitung von Erico Mendonca.
Das resultierende ISO ist mit 7,9 GB Größe kein Leichtgewicht aber sollte lt. Erico in 99% der Fälle (auch bei EFI Boot) funktionieren.
Azure: AZ CLI 2.0 auf Mac installieren
Für die Installation der Azure CLI auf macOS geht man folgendermaßen vor:
- Wir starten ein Terminal auf macOS
Folgendes Skript muss gestartet werden:
curl -L https://aka.ms/InstallAzureCli | bash
- Der erste Prompt frägt nach dem default Installationsverezeichnis. Entweder anpassen oder per Default mit „enter“ übernehmen.
- Die zweite Frage „In what directory would you like to place the ‘az’ executable?“ gibt ebenfalls einen Default mit, nämlich „Homeverzeichbnis/bin“. Entweder anpassen oder den Default übernehmen mit „enter“
- Anschließend wird Azure CLI 2.0 heruntergeladen und extrahiert. Kurze Wartezeit -> Kaffee holen
- Nach dem Fertigstellen kommt noch eine Interaktion mit der Frage:
„Modify profile to update your $PATH and enable shell/tab completion now?“. Wir bestätigen mit Enter, damit wird die ~/.bash_profile erweitert. Ich habe mir noch Kommentarzeilen dazu gesetzt da meine .bash_profile bereits verschiedene Einträge enthält:
Um die Einträge in der ~/.bash_profile zu übernehmen solltet ihr eure shell einmal schließend und wieder öffnen! Alternativ „exec -l $SHELL“.
Anschließend können wir die Azure CLI 2.0 testen mit den folgenden Befehlen:
az login
Hierbei wir euer Browser gestartet bei dem ihr euch Authentifizieren müsst. Anschließend seid ihr zu eurem Azure Konto verbunden.
Ihr bekommt eine Übersicht über die AZ CLI Befehle mit:
az -h
Mit „az account list“ bekommt ihr eine Übersicht über eure User mit den jeweiligen Subscriptions sobald ihr eingeloggt seid.
az account list --output table
Linux: sudo – have fun with sudo
Heute haben mich Teilnehmer in einem Linux Workshop auf den folgenden Absatz in der sudo Konfigurationsdatei /etc/sudoers aufmerksam gemacht:
## Do not insult users when they enter an incorrect password. Defaults !insults
Irgendwie ist mir dieser Eintrag bei SLES bisher noch gar nie aufgefallen. Also wurde direkt mal ausprobiert was es damit auf sich hat.
Meinem User „thorsten“ auf dem System wurden Adminrechte über sudo erteilt. Er muss allerdings das PW für die Adminrechte angeben. Anschließend habe ich das PW mit Absicht falsch angegeben. Resultat:
😀 Was musste ich lachen…
Die „Beleidigungen“ sind übrigens in dieser Datei enthalten: /usr/lib/sudo/sudoers.so
RedHat Server – Cheatsheets
Ich bin vorhin über folgenden RedHat Artikel gestolpert welcher die Administrativen Tools der RHEL Releases übersichtlich zusammenfasst. Welche Tools sind für RedHat 5/6/7 die aktuellen Tools:
https://access.redhat.com/articles/1189123
Zudem sind im Attachment des Artikels verschiedene Cheatsheets enthalten. Falls jemand nen A2 Drucker zuhause hat kann er damit vermutlich seine Zimmer tapezieren 😉
sudoers – How-To Exclusion List
Vor Kurzem lief mir folgendes Scenario über den Weg:
Ein SAP System wird auf SLES 12 Server betrieben. Hier haben zum einen die Administratoren Zugang, unteranderem aber auch die Kollegen aus dem Support Team.
Da die Benutzer sich nur via Named-Usern am Linux Anmelden können, müssen diese, um Administrative Rechte zu erlangen, mit sudo einen Benutzerwechsel durchführen.
Bisher war die Konfiguration recht einfach gehalten: Alle Named-User hatten komplette root Rechte über sudo.
Um nun zu verhindern, dass die Benutzer des Supports in den Kontext des Benutzers root oder weiteren erhöhten Benutzern wechseln können, kann man in der sudoers eine Exclusion List definieren.
Definiert wird die Liste mit Hilfe eines Alias. Hierfür gibt es den sogenannten Runas_Alias.
zB.:
Runas_Alias RESTRICTED = rootEbenso Definiert man einen User_Alias für die Benutzer:
User_Alias AD_SUPPORT_USER = %support_user
Vorweg der Logische Aufbau eines sudoers Eintrags:
<Benutzer/Alias> <Quell Host> = <User Kontext> <Kommando>
Nun baut man auf folgende Weise den sudoers Eintrag zusammen:
AD_SUPPORT_USER ALL = (ALL,!RESTRICTED) NOPASSWD:ALLDer Eintrag bewirkt folgendes:
Alle Benutzer, welche Bestandteil des Alias AD_SUPPORT_USER sind, dürfen von jedem Host, alle Befehle ausführen und in jeden Benutzer Kontext wechseln, außer zu jenen Usern welche in dem Alias RESTRICTED definiert sind. Das ganze, ohne Passwortabfrage, da die Option NOPASSWD gesetzt ist.
Durch den Eintrag des Benutzer Kontextes legt man fest dass alle Benutzer (ALL) außer die Benutzer des Alias RESTRICTED (!RESTRICTED) verwendet werden dürfen.
Die Mitarbeiter können zum Beispiel mit Hilfe des folgenden Befehls:
sudo -u www-data /bin/bashin eine BASH Session des Benutzers www-data wechseln.
bash – history Funktionalität „Leerzeichen“
Heute bin ich über eine kleine bash Funktionalität gestolpert. Normalerweise werden alle eingegebenen Befehle auf der Bash Shell in der Historie gespeichert und können ja über den „history“ Befehl oder über Angabe der „Zeilennummer“ mit einem Ausrufezeichen wiederholt werden.
Beispiel
$ history 826 [2018-02-08 19:25:05] date 827 [2018-02-08 19:25:22] history 828 [2018-02-08 19:37:18] top $ !826 date Do 8. Feb 19:44:22 CET 2018
Wenn nun aber vor dem eigentlich Befehl ein Leerzeichen mit auf er bash eingegeben wird taucht der Befehl NICHT in der history auf. Der Befehl ist auch nicht über die „Pfeil hoch“ Tasten verfügbar.
$ cal $ history 826 [2018-02-08 19:25:05] date 827 [2018-02-08 19:25:22] history 828 [2018-02-08 19:37:18] top 829 [2018-02-08 19:44:22] date 830 [2018-02-08 19:50:23] history
Man beachte bei der Eingaben von „cal“ den Minimal größeren Abstand.
Dies kann sehr hilfreich sein wenn man aus irgendwelchen Gründen ein PW in der Kommandozeile eingeben möchte ohne das dieses in der Historie landet.
Ich habe versucht das selbe mit einer csh zu reproduzieren. Hat nicht funktioniert.
Synology: HyperBackup Bandbreitenbegrenzung
Für eine externe Datensicherung meiner wichtigsten Daten sichere ich von meiner Synology über HyperBackup auf eine zweite Synology Diskstation.
Nun ist meine Internetbandbreite nicht allzu hoch, gerade was den Upload betrifft, und HyperBackup nutzt sogleich die komplette Upload Bandbreite wenn es die Sicherung durchführt. Egal ob initiales Backup oder Differentielles Backup später möchte ich hier nicht meine komplette Bandbreite opfern.
Bei der Diskstation gibt es unter:
Systemsteuerung -> Netzwerk -> Datenfluss-Steuerung
die Möglichkeit die Bandbreite für eine Vielzahl von Diensten bzw. auf Portebene ein zu grenzen.
Hier sind auch vordefinierte Dienste wie „HyperBackup“ hinterlegt. Meiner Erfahrung nach funktioniert aber zumindest die Defaultregel für HyperBackup nicht.
Wenn man die Bandbreite einschränken möchte legt man sich eine Custom Regel an.
RSS Feed
Alle Beiträge unter CC–BY–SA 3.0 unported
Diese(s) Werk(e) bzw. Inhalt(e) von Thorsten Geister steht/stehen unter einer Creative Commons Namensnennung-Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.
Beruht auf einem Inhalt unter linux-voodoo.de.