CQ 5.5: Rien ne va plus - Ich brauche ein Text-Shell

Sie haben versehentlich den HTTP-Dienst oder die Webkonsole angehalten und können nicht mehr auf das System zugreifen. Oder Ihr Repository ist abgestürzt und die Webkonsole lässt Sie das Repository nicht einfach reparieren. Oder Sie suchen nach der CRX-Konsole aus früheren Versionen von CRX.

Lösung

In diesem Dokument wird erläutert, wie Sie eine textbasierte Befehlszeilen-Shell installieren können, mit deren Hilfe Sie diese und möglicherweise andere Probleme beheben können.

Schlüsselfiguren

Der Schlüssel zur Lösung besteht darin, die Befehlszeilenschnittstelle zum OSGi-Framework zu verwenden, das von der Apache Felix Gogo Shell bereitgestellt wird. Wie es in der OSGi-Welt üblich ist, kommt die Gogo Shell als eine Sammlung von Bundles:

• Apache Felix Gogo Runtime -- Die zentrale Shell-Laufzeit. Dieses Bundle enthält die zentrale API und die Integrationsfunktionalität zum Ausführen einer Befehls-Shell.
• Apache Felix Gogo Befehl -- Die grundlegenden Befehle für die OSGi-Framework-Wartung. Dieses Bundle enthält Befehle zum Sich-Prüfen und Bearbeiten, sowie zum OSGi-Framework und seinen Bundles.
• Apache Felix Gogo Shell -- Die Text-Shell-Funktionalität. Dieses Bundle bietet eine grundlegende lokale Shell (in Granite-basierten Anwendungen standardmäßig deaktiviert), auf der die Remoting-Funktionen basieren.
• Apache Felix Webkonsole Gogo Shell Plugin -- Text-Shell-Unterstützung in der Webkonsole. Dieses Bundle erweitert das Gogo-Shell-Bundle, indem die Text-Shell in der Webkonsole verfügbar gemacht wird.
• Apache Felix Remote Shell -- Telnet-Stil Text-Shell-Unterstützung. Dieses Bundle erweitert das Gogo-Shell-Bundle, indem die Text-Shell über TCP/IP verfügbar gemacht wird.

Sie finden weitere Informationen zur Gogo Shell auf der Apache Felix-Seite.

Erforderliche Grundlagen

Die zentralen Bundles -- Laufzeit, Befehl und Shell -- sind essentiell und werden immer benötigt.

Zugriff auf die Webkonsole.

Wenn der Zugriff auf die Webkonsole weiterhin möglich ist, wird die Verwendung des Gogo-Shell-Plugins der Webkonsole für den Remote Shell-Zugriff empfohlen.

Telnet-Zugriff

Wenn der Zugriff auf die Webkonsole nicht mehr möglich ist - wenn zum Beispiel der HTTP-Dienst tot ist oder die Webkonsole selbst funktioniert nicht mehr - können Sie vielleicht das Remote Shell-Bundle installieren.

Im Gegensatz zum Gogo-Shell-Plugin der Webkonsole, erlaubt das Remote Shell-Bundle *keinen* echten Fernzugriff. Aus Sicherheitsgründen hört das Remote Shell-Paket standardmäßig nur Port 6666 auf localhost (127.0.0.1) ab. Der Zugriff ist nur aus derselben Box möglich.

Überlegungen zur Sicherheit.

Webkonsole

Der Zugriff auf das Gogo Shell-Plugin der Webkonsole wird, wie alles in der Webkonsole, durch einfache Authentifizierung und grundlegende Zugriffskontrolle geschützt. Zum Beispiel ermöglicht der Sling-Webkonsolen-Sicherheitsanbieter standardmäßig, dass der Administrator-Benutzer auf die Webkonsole zugreifen kann.

Daher sollte die Webkonsole natürlich auch nicht über den Dispatcher dem öffentlichen Internet zugänglich gemacht werden.

Telnet

Das Remote Shell-Bundle implementiert keinerlei Zugriffskontrolle. Die einzige grundlegende Sicherheit, die implementiert wurde, ist, dass standardmäßig nur Zugriff auf localhost (127.0.0.1) möglich ist. Dies bedeutet, dass eine Remote-Shell für den Host (zum Beispiel eine SSH-Sitzung) erforderlich ist, bevor ein Telnet in die Remote-Shell möglich ist.

Das Remote Shell-Bundle ist auch nicht dazu gedacht, um standardmäßig und über einen längeren Zeitraum aktiv zu sein. Das Paket sollte im Notfall installiert werden und sollte nach der Lösung des Notfallproblems deinstalliert werden, um potenzielle Probleme zu vermeiden. Keine reguläre Funktionalität sollte nur auf dem Remote Shell-Bundle basieren.

Installation

Installation des Inhaltspakets.

Wenn das JCR-Repository noch funktionsfähig ist und über HTTP erreichbar ist, ist es am einfachsten, das angehängte Gogo Shell Inhaltspaket zu installieren. Dieses Inhaltspaket enthält die Gogo Laufzeit-, Befehls- und Shell-Bundles sowie das Gogo-Shell-Plugin der Webkonsole.

Es enthält nicht die Remote Shell aufgrund von Sicherheitsbedenken und weil es in dieser Situation nicht wirklich benötigt wird.

Installation der Webkonsole.

Wenn das JCR-Repository nicht mehr verfügbar ist, aber auf die Webkonsole zugegriffen werden kann, können Sie das angehängte Gogo Shell-Inhaltspaket herunterladen und entpacken und die enthaltenen Bundles über die Webkonsole hochladen.

Auch hier sollte das Remote Shell-Bundle aus Sicherheitsgründen nicht installiert werden, da es nicht wirklich benötigt wird.

Notfallinstallation

Sie müssen auf die lokale Installation der Gogo Shell zurückgreifen, in Fällen in denen Sie Notfallprobleme lösen wollen, bei denen weder das JCR-Repository noch die Webkonsole bedienbar und zugänglich sind. Diese Installation erfordert Zugriff auf das Dateisystem und Zugriff auf Shell.

Die grundlegenden Installationsschritte sind wie folgt:

1. Rufen Sie eine textbasierte Sitzung für das System auf, auf dem die Granite-Anwendung ausgeführt wird.
2. Erstellen Sie einen Installations-Ordner im Anwendungsordner von Granite (normalerweise unter CRX-Quickstart.
3. Laden Sie das angehängte Gogo-Shell-Inhaltspaket herunter und entpacken Sie es.
4. Kopieren Sie die Gogo Laufzeit-, Befehls- und Shell-Bundles in den crx-quickstart/install-Ordner.
5. Laden Sie das angehängte Remote Shell-Bundle herunter und kopieren Sie es in den crx-quickstart/install-Ordner.

Das OSGi-Installationsprogramm, das in der Granite-basierten Anwendung ausgeführt wird, übernimmt automatisch die Bundles aus dem Ordner crx-quickstart/install und installiert und startet sie. Sie müssen möglicherweise ein paar Sekunden warten, damit dies geschieht.

Sie können sich nach der Installation per Telnet in die Gogo Shell einloggen, die standardmäßig Port 6666 überwacht:

$ telnet localhost 6666
Versuche 127.0.0.1...
Verbunden mit dem localhost.
Escape-Zeichen lautet „^]“.
_
Willkommen zu Apache Felix Gogo

g!

Wenn alles gut geht, erhalten Sie die Befehlsaufforderung -- g! -- Von der Gogo Shell, wo Sie Befehle wie Hilfe (um eine Liste der verfügbaren Befehle abzurufen) und lb (um laufende Bundles aufzulisten) ausführen können.

Sie finden weitere Informationen zur Gogo Shell auf der Apache Felix-Seite.

Wiederherstellung von einem gestoppten HTTP-Service-Bundle

Führen Sie für eine Wiederherstellung nachdem das HTTP-Service-Bundle unbeabsichtigt gestoppt wurde die folgenden Schritte aus:

1. Installieren Sie die Gogo Shell-Bundles wie oben im Abschnitt Notfallinstallation beschrieben.
2. Starten Sie die Shell-Sitzung mit dem Telnet-Befehl:
   $ telnet localhost 6666
   Trying 127.0.0.1...
   Connected to localhost.
   Escape-Zeichen lautet „^]“.
   _
   Willkommen zu Apache Felix Gogo
   
   g!
3. Verwenden Sie den Befehl lb, um das HTTP-Service-Bundle aufzulisten. Wir nehmen an, dass dieses Bundle den HTTP-Dienst in seinem Namen hat, daher verwenden wir dieses (angeführt) als Argument für den Befehl lb :
   g! lb "http service"
   START LEVEL 30
   ID|State |Level|Name
   21|Resolved | 5|Day CQSE HTTP Service (4.1.32)
   g!
   
4. Von der Ausgabe sehen wir, dass das CQSE HTTP Service Bundle tatsächlich nicht aktiv ist. Daher verwenden wir den Befehl Start mit der ID 21 des Bundles als Argument:
   g! start 21
   g!
5. So weit, so gut. Lassen Sie uns das Ergebnis überprüfen:
   g! lb "http service"
   START LEVEL 30
   ID|State |Level|Name
   21|Active | 5|Day CQSE HTTP Service (4.1.32)
   g!
6. Verwenden Sie den Befehl lb, um zu überprüfen, ob auch andere Bundles gestartet wurden. Insbesondere sollten Sie überprüfen, ob die Web Management-Konsole und die Plugins aktiv sind:
   g! lb-Konsole
   START LEVEL 30
   ID|Status |Ebene|Name
   24|Aktiv | 5|Apache Felix Web-Management-Konsole (3.4.1.R1334005)
   25|Aktiv | 5|Apache Felix Webkonsole-Service-Komponente Laufzeit-/Deklarative-Dienste-Plugin (1.0.0.R1201749)
   26|Aktiv | 5|Apache Felix Webkonsole-Ereignis-Plugin (1.0.2)
   27|Aktiv | 5|Apache Felix Webkonsole Speicherverwendungs-Plugin (1.0.2)
   28|Aktiv | 5|Apache Felix Webkonsole Paket-Admininistrator-Service-Plugin (0.0.1.R1233342)
   55|Aktiv | 15|Apache Sling Webkonsole Sicherheitsanbieter (1.0.0)
   74|Aktiv | 20|Adobe Granite Workflow-Konsole (0.0.4)
   138|Aktiv | 20|Apache Felix Web Gogo Shell Plugin (0.0.1.R1238480)
   g!
   Hier sieht alles gut aus. Hier gibt es also nichts mehr zu tun.
7. Sie können nun die Shell durch die Eingabe von Strg-D verlassen.
8. Sie sollten nun das Remote Shell-Bundle deinstallieren, indem Sie es aus dem Ordner crx-quickstart/install entfernen (Sie können es jedoch bei Bedarf erneut installieren).

Sie sollten jetzt mit Ihrem Browser auf die Anwendung zugreifen können.

Zugriff auf das Repository.

Beginnend mit CRX 2.3.18 (im CQ 5.5 Update 1 enthalten), kann auf das Repository mit der Gogo Shell zugegriffen werden. Dies kann mit dem oben beschriebenen Telnet-Befehl oder mit einem Webbrowser (http://localhost:4502/system/console/gogo) erfolgen. Alle CRX-bezogenen Befehle haben ein crx:-Präfix. Sie können diese auflisten, indem Sie crx:help eingeben.

Verfügbare Befehle:
add         fügt einen neuen Knoten oder einen untergeordneten Knoteneintrag hinzu.
Bundlecheck prüft Knoten-Bundles,
cd          ändert den aktuellen Arbeitsknoten.
check       prüft das Repository,
checkin     führt einen Checkin auf einem Knoten durch.
checkout    führt einen Checkout auf einem Knoten durch.
clone       klont einen Knoten.
connect     verbindet sich mit einem CRXRepository.
cp          kopiert einen Knoten.
echo        druckt die Argumente auf die Konsole,
help        druckt diese Hilfe,
login       führt eine Anmeldung am Repository aus.
logout      führt eine Abmeldung am Repository aus.
Is          druckt die Liste der Knoten von Eigenschaften.
mixin       manipuliert den Satz von Mixin-Knotenarten eines Knotens.
mv          bewegt einen Knoten.
patch       verlsieht Daten einer niedrigen Ebene eines Elementstatus mit Patches.
print       druckt die Definition eines Knotens oder einer Eigenschaft.
pwd         druckt den aktuellen Pfad.
refresh     aktualisiert einen Knoten, eine Eigenschaft oder eine Sitzung,
rm          entfernt einen Knoten oder eine Eigenschaft.
save        speichert einen Knoten, eine Eigenschaft oder eine Sitzung,
spool       spult (kopiert) einen Arbeitsbereich.
stat        druckt die Information auf niedriger Ebene (Persistenz) eines Knotens oder einer Eigenschaft.
workspace   verwaltet den Arbeitsbereich.

Pfade:
Pfade können entweder
- relativ zum cwd sein (zum Beispiel „./foo/bar“)
- absolut (zum Beispiel „/foo/bar“)
- oder UUID-relativ (zum Beispiel „[cafebabe-cafe-babe-cafe-babecafebabe]/foo/bar“).

Verwenden Sie „help -d“, um die Details für alle Befehle aufzulisten, oder
verwenden Sie „help <cmd>“ für einen bestimmten Befehl.

Wenn Sie Repository-Inkonsistenzen beheben möchten, können Sie folgendes versuchen:

1. Starten der Konsole
   $ telnet localhost 6666
   Versuche 127.0.0.1...
   Verbunden mit dem localhost.
   Escape-Zeichen lautet „^]“.
   _
   Willkommen zu Apache Felix Gogo.
   
2. Melden Sie sich mit den Administrator-Anmeldedaten im Standardarbeitsbereich an
   g! crx:login admin admin
   erfolgreich als Administrator im crx.default
   -Arbeitsbereich angemeldet.
3. Anzeige der Beschreibung der Bundlecheck-Methode
   g! crx:help bundlecheck
   Synopsis:
   bundlecheck [options] [path | uuid]
   
   Description:
   Prüft entweder das Bundle des aktuellen Knotens, das Bundle für einen bestimmten Knotenpfad, das Bundle
   für eine Knoten-UUID oder alle gespeicherten Bundles (unabhängig von der Hierarchieinformation). Dieser Befehl
   funktioniert nur mit Bundle-Persistenzmanagern (zum Beispiel DB-Bundle und TarPM).
   
   Optionen:
   -a prüft alle Bündel im PM-Speicher (-r trifft nicht zu),
   -r prüft rekursiv die Unterknoten,
   -f versucht, die fehlenden untergeordneten Knotenfehler zu beheben,
   -p druckt Knotenpfade und prüft übergeordnete Beziehungen (langsamer),
   -x prüft Knotenreferenzen (langsamer),
   -X prüft Knotenreferenzen und entfernt ungültige (langsamer),
   -e druckt nur Fehler (schneller),
   -o <file> Sicherheitskopieausgabe in Datei.
   -l <path> bewegt verwaiste Knoten zu diesem verlorenen+gefundenen übergeordneten Knoten.
   
4. Zeigt das Wurzelverzeichnis an
   g! crx:ls
   + /
   + bin
   + rep:repoPolicy
   + rep:policy
   + jcr:system
   + var
   + libs
   + etc
   + apps
   + home
   + tmp
   + content
   - sling:resourceType
   - jcr:mixinTypes
   - sling:target
   - jcr:primaryType
   
5. Erstellen eines Verloren+Gefunden-Ordners
   g! crx:add lost+found
6. Speichern der Sitzung
   g! crx:save
7. Erneutes Überprüfen der Struktur des Stammverzeichnisses (überprüfen des Verloren+Gefunden-Ordners)
   g! crx:ls
   
   + /
   + bin
   + rep:repoPolicy
   + rep:policy
   + jcr:system
   + var
   + libs
   + etc
   + apps
   + home
   + tmp
   + content
   + lost+found
   - sling:resourceType
   - jcr:mixinTypes
   - sling:target
   - jcr:primaryType
   
8. Durchführen des Bundlechecks:
   g! crx:bundlecheck -rfel lost+found
   Verwenden des Knotens b006af08-d78c-44b3-b847-58472e7962cc als übergeordneten Knoten für verwaiste Knoten.
   1000 Knoten überprüft mit 0 Fehler(n) bis jetzt.
   ...
   66.000 Knoten bis jetzt überprüft mit 0 Fehler(n).
   Konsistenzüberprüfung von 66.717 Knoten in 110.015 Millisekunden abgeschlossen.
   Keine Fehler gefunden.