Problema
Você parou o Serviço HTTP ou o Console da Web sem avisar e não pode mais acessar o sistema. Ou o repositório caiu e o Console da Web simplesmente não permite a correção do repositório com facilidade. Ou o Console CRX procurado é de versões anteriores do CRX.
Solução
Este documento explica como instalar um shell de linha de comando baseado em texto, ajudando na recuperação desses e talvez outros problemas.
Jogadores-chave
A chave para a solução é usar a interface da linha de comandos para a estrutura OSGi que é fornecido pelo Apache Felix Gogo Shell. Como é costume no mundo OSGi, o Gogo Shell vem como uma coleção de pacotes:
- Tempo de execução do Apache Felix Gogo -- O tempo de execução do shell principal. Esse pacote fornece a API principal e a funcionalidade de integração para executar um shell de comando.
- Comando Apache Felix Gogo -- Os comandos básicos para manutenção da estrutura OSGi. Este pacote fornece comandos para introspecção, manipulação, estrutura OSGi e seus pacotes configuráveis.
- Apache Felix Gogo Shell -- A funcionalidade do shell de texto. Esse pacote fornece um shell local básico (desativado por padrão em aplicativos baseados em Granito) no qual os recursos remotos são baseados.
- Apache Felix Web Console Plugin Gogo Shell -- Suporte a Shell de Texto dentro do Console da Web. Esse pacote estende o Gogo Shell, expondo o shell de texto no Console da Web.
- Shell Remoto do Apache Felix -- suporte ao shell de texto no estilo Telnet. Este pacote estende o Gogo Shell, expondo o shell de texto sobre TCP/IP.
Mais informações sobre a Gogo Shell estão disponíveis em the Apache Felix site.
Fundamentos Necessários
Os pacotes principais -- Tempo de Execução, Comando e Shell -- são essenciais e são sempre necessários.
Web Console Access
Se o acesso ao Console da Web ainda for possível, o uso do plug-in Gogo Shell do Console da Web é recomendado para acessar o shell remotamente.
Telnet Access
Se o acesso ao Console da Web não for mais possível -- por exemplo, o Serviço HTTP está inativo ou o próprio Console da Web não funciona mais -- é possível instalar o pacote do Shell Remoto.
Ao contrário do Plug-in Gogo Shell do Console da Web, o pacote Shell Remoto *não* permite o acesso remoto verdadeiro. Por motivos de segurança, o pacote configurável do Shell Remoto, por padrão, recebe apenas a porta 6666 no host local (127.0.0.1). Assim, o acesso só é possível a partir da mesma caixa.
Considerações de segurança
Web Console
O acesso ao Plug-in do Console da Web do Gogo Shell é guardado, por meio de autenticação simples e controle de acesso básico. Por exemplo, o provedor Sling Web Console Security fora da caixa permite apenas que o usuário admin acesse ao Console da Web.
Como tal, o Console da Web, obviamente, também não deve ser exposto à Internet pública através do Dispatcher.
Telnet
O pacote do Shell Remoto não implementa nenhum controle de acesso. Por padrão, a única segurança básica implementada é que apenas o acesso ao host local (127.0.0.1) é possível. Isso significa que é necessário um shell remoto para o host (por exemplo, uma sessão SSH) antes de poder fazer telnet no Shell Remoto.
Além disso, o pacote Shell Remoto não se destina a ser ativo por padrão e ao longo do tempo. O pacote deve ser instalado em caso de emergência e deve ser desinstalado depois de resolver o problema para evitar possíveis complicações. Nenhuma funcionalidade regular deve ser baseada somente no pacote Shell Remoto.
A instalação
Content Package Installation
Se o repositório JCR ainda é operável e acessível por HTTP, a melhor coisa a fazer é instalar o repositório anexado Gogo Shell Content Package. Esses pacotes de conteúdo fornecem os pacotes configuráveis Tempo de Execução, Comando e Shell Gogo, assim como o Plug-in do Gogo Shell do Console da Web.
Não inclui o Shell Remoto devido a preocupações de segurança e porque não é realmente necessário nesta situação.
Web Console Installation
Se o Repositório JCR não está mais disponível, mas o Console da Web é acessível, é possível baixar e descompactar o Gogo Shell Content Package e carregar os pacotes contidos pelo Console da Web.
Novamente, o pacote do shell remoto não deve ser instalado neste caso devido a preocupações de segurança e porque não é necessário.
No caso de resolver problemas de emergência em que nem o Repositório JCR, nem o Console da Web estão operacionais e acessíveis, é preciso recorrer à instalação local do Gogo Shell. Esta instalação requer acesso ao sistema de arquivos e acesso ao shell.
As etapas básicas de instalação são as seguintes:
- Obtenha uma sessão baseada em texto para o sistema que executa o aplicativo Granite
- Crie uma pasta install na pasta do aplicativo Granite (geralmente abaixo de crx-quickstart)
- Baixe e descompacte o arquivo anexado Pacote de conteúdo do Shell Gogo
- Copie os pacotes Gogo Runtime, Command e Shell para a pasta crx-quickstart/install
- Baixe o anexo Pacote remoto do shell e copie-o para a pasta crx-quickstart/install
O instalador do OSGi em execução no aplicativo baseado no Granite selecionará automaticamente os pacotes da pasta crx-quickstart/install e os instalará e iniciará. Pode ser necessário esperar alguns segundos para que isso aconteça.
Após a instalação, é possível fazer o telnet no Gogo Shell, que escuta na porta 6666 por padrão:
$ telnet localhost 6666
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
_
Welcome to Apache Felix Gogo
g!
Se tudo correr bem, o prompt de comando da Gogo Shell -- g! -- é exibido, e é possível começar a executar comandos como help (para obter uma lista dos comandos disponíveis) e lb (para listar pacotes em execução).
Consulte o site do Apache Felix para saber mais sobre o Gogo Shell.
Recuperação de um pacote de serviços HTTP parado
Para recuperar um pacote de serviço HTTP interrompido inadvertidamente, siga estas etapas:
- Instale os pacotes do Gogo Shell, conforme explicado acima na seção Instalação de emergência
- Inicie a sessão do shell usando o comando telnet:
$ telnet localhost 6666
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
_
Welcome to Apache Felix Gogo
g! - Use o comando lb para listar o pacote do serviço HTTP. Nós assumimos que este pacote tem http service no nome, então usamos isso (entre aspas) como o argumento para o comando lb:
g! lb "http service"
START LEVEL 30
ID|State |Level|Name
21|Resolved | 5|Day CQSE HTTP Service (4.1.32)
g! - Na saída, vemos que, de fato, o pacote do serviço HTTP do CQSE não está ativo. Então usamos o comando start com a ID do pacote (21) como o argumento:
g! start 21
g! - Por enquanto, tudo bem. Vamos verificar o resultado:
g! lb "http service"
START LEVEL 30
ID|State |Level|Name
21|Active | 5|Day CQSE HTTP Service (4.1.32)
g! - Use o comando lb para verificar que outros pacotes também foram iniciados. Especificamente, verifique se o console de gerenciamento da Web e os plug-ins estão ativos:
g! lb console
START LEVEL 30
ID|State |Level|Name
24|Active | 5|Apache Felix Web Management Console (3.4.1.R1334005)
25|Active | 5|Apache Felix Web Console Service Component Runtime/Declarative Services Plugin (1.0.0.R1201749)
26|Active | 5|Apache Felix Web Console Event Plugin (1.0.2)
27|Active | 5|Apache Felix Web Console Memory Usage Plugin (1.0.2)
28|Active | 5|Apache Felix Web Console Package Admin Service Plugin (0.0.1.R1233342)
55|Active | 15|Apache Sling Web Console Security Provider (1.0.0)
74|Active | 20|Adobe Granite Workflow Console (0.0.4)
138|Active | 20|Apache Felix Web Gogo Shell Plugin (0.0.1.R1238480)
g!
Tudo parece certo aqui. Então, nada mais a fazer. - Saia do shell digitando Ctrl+D
- Agora desinstale o pacote do shell remoto removendo-o da pasta crx-quickstart/install (ainda é possível reinstalá-lo, caso seja necessário).
Agora você deve conseguir acessar o aplicativo com seu navegador.
Acessar o repositório
A partir do CRX 2.3.18 (incluído no CQ 5.5 Atualização 1), o repositório pode ser acessado usando o gogo shell. Isso pode ser feito usando o comando telnet descrito acima ou um navegador da Web (http://localhost:4502/system/console/gogo). Todos os comandos relacionados ao CRX têm o prefixo crx:. Liste-os digitando crx:help
Available commands:
add Adds a new node or child node entry.
bundlecheck Checks node bundles
cd Changes the current work node.
check Checks the repository
checkin Does a checkin on a node.
checkout Does a checkout on a node.
clone Clones a node.
connect Conecta a um CRXRepository.
cp Copies a node.
echo Prints the arguments to the console
help Prints this help
login Perform a login on the repository.
logout Perform a logout on the repository.
ls Prints the list of nodes of properties.
mixin Manipulates the set of mixin nodetypes of a node.
mv Moves a node.
patch Patch lowlevel data of an item state.
print Prints the definition of a node or a property.
pwd Prints the current path.
refresh Refreshs a node, property or session
rm Removes a node or property.
save Saves a node, property or session
spool Spools (copies) a workspace.
stat Prints the lowlevel (persistence) information of a node or a property.
workspace Manages workspaces
Paths:
Paths can be specified either
- relative to the cwd (i.e. './foo/bar')
- absolute (i.e. '/foo/bar')
- or uuid-relative (i.e. '[cafebabe-cafe-babe-cafe-babecafebabe]/foo/bar')
Use 'help -d' to list the details for all commands or
use 'help <cmd>' for a specific command.
Se você deseja corrigir inconsistências de repositório, tente:
- Inicie o console
$ telnet localhost 6666
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
_
Welcome to Apache Felix Gogo
- fazer login no espaço de trabalho padrão usando credenciais de administrador
g! crx:login admin admin
conectado com sucesso como administrador no espaço de trabalho crx.default
- exibir a descrição do método bundlecheck
g! crx:help bundlecheck
Synopsis:
bundlecheck [options] [path uuid]
Description:
Checks either the current node's bundle, the bundle for a given node path, the bundle
for a node UUID or all stored bundles (regardless of hierarchy information). This command
only works with bundle persistence managers (eg. pacote de BD e TarPM).
Options:
-a check all bundles in the PM storage (-r does not apply)
-r recursively check subnodes
-f try to fix missing child node errors
-p print node paths and verify parent relations (slower)
-x check node references (slower)
-X check node references and remove invalid (slower)
-e only print errors (faster)
-o <file> dump output to file.
-l <path> move orphaned nodes to this lost+found parent node
- exibir o diretório raiz
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
- criar uma pasta de lost+found
g! crx:add lost+found - salvar a sessão
g! crx:save - verificar novamente a estrutura do diretório raiz (verificar a pasta lost+found)
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 - executar bundlecheck:
g! crx:bundlecheck -rfel lost+found
Using node b006af08-d78c-44b3-b847-58472e7962cc as parent for orphaned nodes.
checked 1000 nodes with 0 error(s) so far.
...
checked 66000 nodes with 0 error(s) so far.
Consistency check of 66717 nodes finished in 110015 milliseconds.
No errors found.
Download
Download