DistroSea mit diversen Linux-Distributionen im Browser
Auf der Suche nach einer einfachen Möglichkeit mal kurz etwas auf eine Linux Kommandozeile zu testen bin ich heute auf ein kleines, aber super umgesetztes Projekt gestoßen: DestroSea.
DistroSea stellt euch heute auf einer aufgeräumten Webpage 39 Live-Linux Systeme zum testen zur Verfügung.
Aktuell wählt man sich eine Distribution aus und bekommt, nach einer Cloudflare verifizierung, innerhalb weniger als einer Minute ein Konsolenbild für die gewählte Live Linux Distribution. Es sind keine Netzwerkkarten oder Festplatten in den VMs verbaut. Aber zum testen reicht das Live-Linux locker.
Ich war positiv überrascht welche recht gute Antwortzeit ich beim Zugriff bekommen habe. Super geeignet für kurze Tests auf der Kommandozeile.
DistroSea finanziert sich über Spenden! Gut angebrachtes kleines Geld 🙂
SAP Software: Migration Sys-V init zu systemd
Mit Einzug von SLES12 und RHEL 7 im Jahre 2014 wurde die bisherige SysV-init Prozessverwaltung auf systemd umgestellt. Die SAP Applikationen (NW, SAP HANA etc.) welche auf neueren SLES oder RedHat Versionen eingesetzt wurden nutzten während der Installation und später im Betrieb einen dynamisch erzeugten Wrapper um weiter unter legacy SysV init Skripte zu arbeiten.
Für SAP Applikationen steht nun seit 2022 bereits eine native systemd Integration mit sapstartsrv zur Verfügung. Für SAP HANA Datenbanken soll die systemd Integration mit Release SAP HANA SPS 07 Einzug erhalten und die bisherige Prozessverwaltung ersetzen.
Bei neu Installierten SAP Produkten ist für Kunden an dieser Stelle kein Handlungsbedarf.
Für Kunden mit bestehenden SAP Systemen auf SUSE oder RedHat Linux muss für die Umstellung eine Migration der Prozessverwaltung mit einer kurzen Downtime geplant werden. Dies lässt sich für Kunden Optimal während eines nächsten OS Patchlaufs kombinieren. Die Umstellung sollten von allen Kunden vorgenommen werden da in zukünftigen OS Releases der Kompatibilitätsmodus / Wrapper nicht mehr zur Verfügung steht.
Weitere Informationen zur Migration von SysV-init zu systemd finden Sie unter folgenden Hinweisen:
- 3139184 – Linux: systemd integration for sapstartsrv and SAP Host Agent
- 3115048 – sapstartsrv with native Linux systemd support
Mehr Informationen zum systemd daemon werden von den OS Distributoren angeboten:
Red Hat:
SUSE:
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.
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.