A partir desta versão, o access-wizard automatiza as etapas de configuração do nó Bootstrap, inicialização do Control Plane, implantação do Control Plane, implantação dos serviços de infraestrutura e do Access e criação de locatários em um único comando guiado. O assistente faz algumas perguntas, grava os arquivos de configuração para você e, em seguida, executa os estágios de implantação em ordem. Se você preferir realizar essas etapas individualmente, consulte Implantar o Omnissa Access manualmente.
Nota: o Access Wizard 26.07 oferece suporte a uma implantação greenfield do Omnissa Access 26.07.0.0. A atualização de uma implantação existente e a implantação de versões posteriores estão fora do escopo desta versão.
Responder ao questionário leva alguns minutos, desde que você tenha os endereços IP, certificados e outras informações necessárias à mão. A implantação automatizada a seguir leva aproximadamente de 1,5 a 2 horas.
Antes de começar
Confirme o seguinte antes de começar:
- As máquinas virtuais Bootstrap, Infraestrutura e Omnissa Access da Fase 1 – Preparar as máquinas virtuais para a instalação do Omnissa Access e Fase 2 – Implantar as máquinas virtuais para a instalação do Omnissa Access estão implantadas e ligadas.
- O balanceador de carga está configurado conforme descrito em Como usar um balanceador de carga ou proxy reverso para habilitar o acesso externo ao Omnissa Access, com os cabeçalhos X-Forwarded-For ativados e escutando na porta 443.
- O DNS do FQDN do seu locatário (por exemplo,
tenant.example.com) aponta para o endereço IP do balanceador de carga. - Você tem a senha do
configuserque foi definida em todos os nós durante a implantação do OVA. Consulte Gerenciar nós do cluster do Omnissa Access Control Plane caso essa senha tenha expirado ou precise ser redefinida. - Você tem um certificado TLS pronto, seja ele autoassinado (o assistente pode gerar um para você) ou um certificado PEM com cadeia completa e a chave privada correspondente, não criptografada, proveniente de sua própria CA.
Notas:
- O assistente valida o espaço em disco e o armazenamento do Docker no nó Bootstrap e verifica a conectividade e a autenticação via SSH com todos os outros nós. Ele não verifica de forma independente o tamanho da CPU, da RAM ou do disco dos nós remotos – confirme esses valores com base na tabela de dimensionamento da Fase 1 – Preparar máquinas virtuais para a instalação do Omnissa Access antes de começar.
- O RPM do Access Wizard possui assinatura digital. A verificação da assinatura (consulte Confiar na chave de assinatura e verificar o RPM, abaixo) é uma verificação separada da verificação da soma de verificação SHA-256 na próxima seção – a soma de verificação confirma que o download não estava corrompido, não que ele seja genuinamente da Omnissa.
Baixar e verificar o Access Wizard
Procedimento:
-
Faça login no Omnissa Customer Connect e baixe:
- O pacote de ativos do Omnissa Access (o arquivo ZIP contendo o manifesto do Control Plane e as imagens de contêiner).
- O pacote RPM do Access Wizard – um arquivo ZIP contendo três itens: o RPM (
access-wizard-26.07.noarch.rpm), seu arquivo de soma de verificação.sha256e a chave pública de assinatura do RPM da Omnissa (omnissa-linux-rpm-gpg-key.pub).
-
Descompacte o pacote RPM em sua máquina local (ou após copiá-lo para o nó Bootstrap – consulte a próxima seção):
unzip <wizard-bundle>.zip -
Verifique o RPM em relação ao arquivo
.sha256incluído no pacote e verifique o pacote de ativos em relação à sua soma de verificação publicada:sha256sum -c access-wizard-26.07.noarch.rpm.sha256 sha256sum <asset-bundle>.zipNão prossiga se algum dos valores não corresponder.
Carregue os arquivos no nó Bootstrap
Procedimento:
-
Copie os dois arquivos ZIP para o nó Bootstrap:
scp <wizard-bundle>.zip <asset-bundle>.zip \ configuser@<bootstrap-ip>:/home/configuser/ -
Conecte-se ao nó Bootstrap como
configusere descompacte o pacote RPM:ssh configuser@<bootstrap-ip> unzip <wizard-bundle>.zipContinue conectado como
configuserdurante o restante deste procedimento. Todos os comandos subsequentes utilizam explicitamentesudo.
Confiar na chave de assinatura e verificar o RPM
Procedimento:
-
Importe a chave pública de assinatura do RPM da Omnissa (execute pelo diretório onde você descompactou o pacote RPM):
sudo rpm --import omnissa-linux-rpm-gpg-key.pub -
Verifique a assinatura e a integridade do RPM:
sudo rpm -K access-wizard-26.07.noarch.rpmA saída deve indicar resumos e assinaturas válidos. Não instale o RPM se a verificação falhar.
Instalar o RPM
Procedimento:
sudo dnf install -y access-wizard-26.07.noarch.rpm
A identidade do pacote instalado é access-wizard-26.07-1.noarch.
Confirmar instalação
Procedimento:
sudo access-wizard --version
Saída esperada:
access-wizard 26.07
Inicie a implantação guiada
Procedimento:
sudo access-wizard deploy --asset-bundle /<path>/<asset-bundle>.zip
O assistente exibe uma tela de boas-vindas listando as seis seções do questionário (Informações básicas, Locatário, Nós de infraestrutura, Nós de acesso, Certificados, Serviços opcionais) e, em seguida, solicita que você pressione Enter para começar.
● OMNISSA ACCESS — Deployment Wizard
Official documentation
• Release Notes
- https://docs.omnissa.com/bundle/workspace-one-access-release-notesV26.07/page/workspace-one-access-release-notes.html
• Install Omnissa Access
- https://docs.omnissa.com/bundle/workspace-one-access-installation-guideV26.07/page/InstallingOmnissaAccess.html
• Deploy Access & Infrastructure
- https://docs.omnissa.com/bundle/workspace-one-access-installation-guideV26.07/page/DeploytheOmnissaAccessandInfrastructureServices.html
View or copy all official documentation URLs: sudo access-wizard docs
-------------------------------------------------------------
Omnissa Access - guided deployment
-------------------------------------------------------------
This wizard asks what it needs, writes your config files, and runs
the deployment in the right order. If a step doesn't validate, it
stops and tells you what to look at rather than pressing on.
There are 6 sections of questions.
The deployment itself takes about two hours. If your connection
drops during it, reconnect and run:
sudo access-wizard resume
It continues from the last completed deployment stage without asking the
questionnaire again.
1. Basic information
2. Tenant
3. Infrastructure nodes
4. Access nodes
5. Certificates
6. Optional services
Press Enter to begin.
Seção 1: Informações básicas
-
Revise o EULA em
https://www.omnissa.com/general-terms/e aceite-o.============================================================= Section 1 of 6: Basic information ============================================================= ------------------------------------------------------------- License agreement ------------------------------------------------------------- Before anything else, please read and accept the end user license agreement. Review it at https://www.omnissa.com/general-terms/ Do you agree to these terms? [Y/n]: EULA accepted <acceptance-timestamp> -
Confirme o pacote de ativos que o assistente localiza automaticamente. O assistente valida sua integridade em relação a uma soma de verificação publicada.
------------------------------------------------------------- Asset bundle verification ------------------------------------------------------------- ✓ Asset integrity <verification-detail> -
Escolha um nome de cluster. Isso determina o caminho do diretório de trabalho,
/opt/wss/<cluster_name>.------------------------------------------------------------- Cluster ------------------------------------------------------------- Choose a short name for this deployment. The wizard creates /opt/wss/<cluster_name>. This becomes the working directory for future WSO administration and maintenance commands. What would you like to call this cluster?: <cluster_name> Working directory will be /opt/wss/<cluster_name> Your answers are saved to /opt/wss/<cluster_name>/wizard.ini -
Escolha o tamanho da implantação – Pequeno, Médio ou Grande. O assistente exibe a topologia dos nós para cada opção.
What size deployment is this? Every deployment uses 3 Infrastructure nodes. The number of Access nodes and supported scale depend on the deployment size. 1) Small 2 Access nodes 300,000 users 3,000 groups 50 apps 2) Medium 2 Access nodes 1,000,000 users 10,000 groups 150 apps 3) Large 3 Access nodes 1,000,000 users 20,000 groups 500 apps Choose 1-3: 1 ✓ Deployment size Small Topology: 3 Infrastructure + 2 Access nodes -
Confirme o endereço IP detectado do nó Bootstrap.
------------------------------------------------------------- This node ------------------------------------------------------------- This looks like the Bootstrap node, with IP address <bootstrap-ip>. Is that right? [Y/n]: Y -
Digite a senha compartilhada
configuser. O assistente a valida imediatamente em relação ao nó Bootstrap. Consulte Gerenciar nós do cluster do Omnissa Access Control Plane para redefinir essa senha, se necessário.------------------------------------------------------------- Credentials ------------------------------------------------------------- The credentials the cluster uses to reach every node. This is the configuser password you already set when you deployed the OVA. Not a new one. It must be the same on every node. Enter the configuser password:******** Enter it again to confirm:******** Validating configuser authentication on Bootstrap (<bootstrap-ip>)... configuser password validated against Bootstrap. -
Escolha como o cluster se autentica nos outros nós: a senha que você acabou de digitar ou um par de chaves SSH gerado.
-
Senha
How should the cluster authenticate to the Infrastructure and Access nodes? 1) password use the password you just entered 2) ssh_key generate a key and copy it to every node Choose 1-2: 1 -
ssh_key
How should the cluster authenticate to the Infrastructure and Access nodes? 1) password use the password you just entered 2) ssh_key generate a key and copy it to every node Choose 1-2: 2
-
-
Digite o endereço IP do balanceador de carga e o endereço IP do X-Forwarded-For, se aplicável à sua implantação. O assistente verifica a conectividade da porta 443.
------------------------------------------------------------- Load balancer ------------------------------------------------------------- The load balancer sits in front of your Access nodes. It should already be configured with X-Forwarded-For headers enabled. You'll add the Access nodes as upstreams once they're deployed. What is the load balancer IP address: <load-balancer-ip> Checking... Load balancer <load-balancer-ip> port 443 reachable ------------------------------------------------------------- X-Forwarded-For trusted proxies ------------------------------------------------------------- The load balancer and Access node IPs are included automatically. Enter only additional trusted proxy, WAF, CDN, or other forwarding-hop IPs. Do you need to add any additional IPs for X-Forwarded-For? [y/N]: y Additional trusted IP: <trusted-proxy-ip> Added <trusted-proxy-ip> Add another trusted IP? [y/N]: n Section 1 complete.
Seção 2: Locatário
Insira o prefixo do locatário e o domínio base – os usuários acessam a implantação em https://<tenant-name>.<base-domain>. O assistente verifica se o FQDN resolve para o endereço IP do balanceador de carga e, em seguida, solicita o nome de usuário do administrador de locatário (padrão: admin), nome, sobrenome e endereço de e-mail.
=============================================================
Section 2 of 6: Tenant
=============================================================
Now configure the tenant your users will sign in to.
Load Balancer URL: https://tenant.acme.example.com
Tenant: tenant
Base domain: acme.example.com
What should the tenant be called: <tenant-name>
What is the base domain: <base-domain>
Users will reach this deployment at:
https://<tenant-name>.<base-domain>
Checking DNS...
<tenant-name>.<base-domain> resolves to <load-balancer-ip>
Matches the load balancer.
-------------------------------------------------------------
Tenant administrator
-------------------------------------------------------------
The first administrator account for this tenant.
What should the administrator's username be? [admin]: admin
Administrator's first name: <first-name>
Administrator's last name: <last-name>
Administrator's email address: <administrator-email>
Section 2 complete.
Seção 3: Nós de infraestrutura
Insira o endereço IP de cada um dos 3 nós de infraestrutura. O assistente verifica a acessibilidade via SSH e autentica cada nó à medida que você o digita. Endereços duplicados são rejeitados.
=============================================================
Section 3 of 6: Infrastructure nodes
=============================================================
Every deployment uses 3 Infrastructure/Platform nodes, regardless
of size.
These run the platform services (Vault, Consul, Nomad) and the
shared infrastructure: PostgreSQL, Redis, Kafka, and OpenSearch.
What is the IP address of Infrastructure node 1: <infra-ip-1>
What is the IP address of Infrastructure node 2: <infra-ip-2>
What is the IP address of Infrastructure node 3: <infra-ip-3>
Checking SSH reachability and authentication on each Infrastructure node...
✓ Infrastructure node 1 <infra-ip-1> reachable and authenticated
✓ Infrastructure node 2 <infra-ip-2> reachable and authenticated
✓ Infrastructure node 3 <infra-ip-3> reachable and authenticated
All 3 Infrastructure nodes are reachable and authenticated.
Section 3 complete.
Seção 4: Nós de acesso
Digite o endereço IP de cada nó do Access (2 para Pequeno ou Médio, 3 para Grande). O assistente verifica a acessibilidade e a autenticação de cada um deles.
=============================================================
Section 4 of 6: Access nodes
=============================================================
Your small deployment uses 2 Omnissa Access nodes.
These run the Access application services and sit behind your load
balancer. Platform services also run here.
What is the IP address of Access node 1: <access-ip-1>
What is the IP address of Access node 2: <access-ip-2>
Checking SSH reachability and authentication on each Access node...
✓ Access node 1 <access-ip-1> reachable and authenticated
✓ Access node 2 <access-ip-2> reachable and authenticated
All 2 Access nodes are reachable and authenticated.
Section 4 complete.
Seção 5: Certificados
Escolha o certificado TLS que o Access usa para o FQDN do locatário:
- Autoassinado – Gerado automaticamente durante a implantação.
- Personalizado – Carregue seu próprio certificado PEM e chave privada para o nó Bootstrap. O assistente valida a cadeia de certificados, a correspondência da chave e a cobertura do FQDN do locatário.
-
Autoassinado
============================================================= Section 5 of 6: Certificates ============================================================= Access needs a TLS certificate for <tenant-name>.<base-domain>. What certificate should Access use? 1) self-signed generated for you during deployment 2) custom your own certificate from a CA Choose 1-2: 1 Section 5 complete. -
Personalizado
============================================================= Section 5 of 6: Certificates ============================================================= Access needs a TLS certificate for <tenant-name>.<base-domain>. What certificate should Access use? 1) self-signed generated for you during deployment 2) custom your own certificate from a CA Choose 1-2: 2 ------------------------------------------------------------- What you need ------------------------------------------------------------- Two files, both PEM format: Certificate complete chain, with the server certificate first, followed by any intermediate CA certificates; the file starts with -----BEGIN CERTIFICATE----- Private key text file starting with -----BEGIN PRIVATE KEY----- or -----BEGIN RSA PRIVATE KEY----- It must not be encrypted or password protected. The certificate must cover <tenant-name>.<base-domain>, as the Common Name or a Subject Alternative Name. A wildcard (*.<base-domain>) also works. Upload both to this node. From your workstation: scp mycert.pem mykey.pem configuser@<bootstrap-ip>:/home/configuser/omnissa-upload/ I've created /home/configuser/omnissa-upload for you. Where are your certificate files? 1) Already uploaded to this node 2) Not yet, I'll upload now - wait for me 3) Actually, use a self-signed certificate instead Choose 1-3: 1 Checking /home/configuser/omnissa-upload... <mycert>.pem <size> KB certificate <mykey>.pem <size> KB private key Found a certificate and key. Use these? [Y/n]: Y Checking the certificate... Format PEM certificate Covers <tenant-name>.<base-domain> (via wildcard *.<base-domain>) Issued by <Issuer> Valid until <date> (<> days from now) Key match yes Certificate accepted. Both files will be copied into place when deployment starts. Section 5 complete.
Seção 6: Serviços opcionais
Quatro itens opcionais: SMTP, NTP, armazenamento compartilhado NFS e Cert-Proxy para SSO móvel no Android. Responda n a qualquer solicitação de [y/N] para adiar esse item. Todos os quatro podem ser revisados após a conclusão da implantação, usando o comando access-wizard configure.
Nota: o nó Bootstrap valida a resolução do nome DNS do servidor NTP que você digitar.
=============================================================
Section 6 of 6: Optional services
=============================================================
Four optional items. All can be configured later if you'd rather
get the deployment running first.
-------------------------------------------------------------
Email (SMTP)
-------------------------------------------------------------
Access sends email for password resets, notifications, and new
user invitations. Without it, the administrator can still sign in
using the reset link created at the end of this deployment, but no
other user will receive email.
Configure SMTP now? [y/N]: n
-------------------------------------------------------------
Time synchronization (NTP)
-------------------------------------------------------------
Cluster nodes need their clocks in sync. Certificate validation and
token expiry both depend on it, so drift causes authentication
failures that are hard to trace.
Do you have an NTP server? [y/N]: n
-------------------------------------------------------------
Shared storage (NFS)
-------------------------------------------------------------
Optional shared storage for the cluster.
Do you have NFS storage to configure? [y/N]: n
-------------------------------------------------------------
Cert-Proxy (Mobile SSO for Android)
-------------------------------------------------------------
Cert-Proxy enables Mobile SSO for Android devices.
It can be configured later if you skip it now.
Configure Cert-Proxy (Mobile SSO for Android)? [y/N]: y
Which certificate should Cert-Proxy use?
1) Reuse the Load Balancer certificate selected above (recommended)
2) Use a different certificate and private key
Choose 1-2: 1
Section 6 complete.
Revisar e confirmar
Após todas as seis seções, o assistente exibe um resumo completo das suas respostas.
=============================================================
Ready to deploy
=============================================================
CLUSTER
Name <cluster_name>
Working directory /opt/wss/<cluster_name>
Size small
Bootstrap <bootstrap-ip>
Load balancer <load-balancer-ip>
Credentials configuser (password set)
Authentication SSH key
password used for initial key distribution
Asset bundle <asset-bundle>.zip
EULA <verification-detail>
TENANT
URL https://<tenant-name>.<base-domain>
Username <username>
Administrator <first-name> <last-name>
Email <administrator-email>
INFRASTRUCTURE NODES
Node 1 <infra-ip-1>
Node 2 <infra-ip-2>
Node 3 <infra-ip-3>
ACCESS NODES
Node 1 <access-ip-1>
Node 2 <access-ip-2>
X-FORWARDED-FOR TRUSTED HOPS
Load balancer <load-balancer-ip>
Access nodes <access-ip-1>, <access-ip-2>
Additional trusted IPs <trusted-proxy-ip>
Final trusted list <load-balancer-ip>, <access-ip-1>, <access-ip-2>, <trusted-proxy-ip>
CERTIFICATE
Type custom
Covers <tenant-name>.<base-domain> (via wildcard *.<base-domain>)
Expires <date>
OPTIONAL
Cert-Proxy enabled (FQDN_CERT)
SMTP not configured
NTP not configured
NFS not configured
-------------------------------------------------------------
This takes roughly 1.5 to 2 hours:
Loading images 5 minutes
Control plane deploy 30-60 minutes
Services deploy 40 minutes
Tenant creation 5-10 minutes
You don't need to stay at the terminal. Progress is shown here
and written to /opt/wss/.omnissa-wizard/logs/
At the end you'll get a password reset link for the
administrator account. It expires in 24 hours, so be ready to
copy it.
Everything above has been saved to /opt/wss/<cluster_name>/wizard.ini
If you stop now, nothing has been changed on any node.
-------------------------------------------------------------
Is everything above correct?
1) Yes, continue to validation
2) No, let me change something
3) Exit without deploying
Choose 1-3:
Escolha 1 para prosseguir para a validação, 2 para alterar algo ou 3 para sair sem implantar.
Is everything above correct?
1) Yes, continue to validation
2) No, let me change something
3) Exit without deploying
Choose 1-3: 1
Em seguida, o assistente exibe um resumo final de prontidão e solicita que você inicie a implantação.
-------------------------------------------------------------
Deploying
-------------------------------------------------------------
✓ Workflow continuation protected from SSH disconnects
-------------------------------------------------------------
Stage 1 of 7 - Validate prerequisites
-------------------------------------------------------------
Checking this Bootstrap node before making deployment changes.
✓ Root privileges running as root
✓ Required commands all available
✓ Node authentication 6 nodes verified (password)
✓ Bootstrap <bootstrap-ip> AlmaLinux 9.6
✓ Infrastructure 1 <infra-ip-1> AlmaLinux 9.6
✓ Infrastructure 2 <infra-ip-2> AlmaLinux 9.6
✓ Infrastructure 3 <infra-ip-3> AlmaLinux 9.6
✓ Access 1 <access-ip-1> AlmaLinux 9.6
✓ Access 2 <access-ip-2> AlmaLinux 9.6
✓ Node OS validation 6 nodes running AlmaLinux 9.6
✓ Asset bundle located access-26.07-assets.zip
✓ Asset bundle structure manifest and Linux CLI found
✓ Working-directory disk space 132 GB available
✓ Docker storage 44 GB available at /var/lib/docker
✓ Disconnect protection systemd transient services
✓ Cluster node connectivity 5/5 answering on SSH
✓ Load balancer port 443 <load-balancer-ip> reachable
✓ Tenant certificate files certificate and key available
Pre-deployment readiness
✓ Bootstrap authenticated · <boostrap-ip>
✓ Infrastructure nodes 3/3 authenticated
✓ Access nodes 2/2 authenticated
✓ Node addresses unique and validated
✓ Configuration ready for deployment
1) Start deployment
2) Review or change configuration
3) Re-enter the shared configuser password
4) Exit safely
Choose 1-4:
Estágios de implantação
O assistente executa os sete estágios a seguir automaticamente. Mantenha a sessão do terminal aberta para monitorar o andamento.
| Estágio | Nome | O que acontece |
|---|---|---|
| 1 | Validar pré-requisitos | Privilégios de root, comandos necessários, autenticação do nó, validação do SO, integridade do pacote de ativos, espaço em disco, verificação do balanceador de carga |
| 2 | Preparar ativos de implantação | Diretório de trabalho, validação e extração do pacote de ativos, instalação da interface de linha de comando, carregamento da imagem do contêiner |
| 3 | Inicializar o cluster | Configuração do cluster, distribuição da chave SSH (se selecionada), inventário do cluster, perfil do Control Plane |
| 4 | Validar o cluster | Pré-verificação da configuração, validação do inventário |
| 5 | Implantar o Control Plane | Vault, Consul, Nomad e serviços da plataforma; validação da integridade da plataforma |
| 6 | Implantar serviços do Access | Perfil de acesso, sincronização de configuração, todos os serviços de aplicativo access, portão de prontidão do serviço |
| 7 | Criar o locatário | Criação do locatário, transferência do reset-link, configuração de SMTP (se selecionado) |
-------------------------------------------------------------
Stage 1 of 7 - Validate prerequisites
-------------------------------------------------------------
✓ Root privileges running as root
✓ Required commands all available
✓ Node authentication 6 nodes verified (password)
✓ Node OS validation 6 nodes running <supported-os>
✓ Asset bundle located <asset-bundle>.zip
✓ Asset bundle structure manifest and Linux CLI found
✓ Working-directory disk space <nn> GB available
✓ Docker storage <nn> GB available at <docker-root>
✓ Disconnect protection systemd transient services
✓ Cluster node connectivity 5/5 answering on SSH
✓ Load balancer port 443 <load-balancer-ip> is listening
✓ Tenant certificate self-signed selected
OK All prerequisites passed
-------------------------------------------------------------
Stage 2 of 7 - Prepare deployment assets
-------------------------------------------------------------
✓ Working directory /opt/wss/<cluster_name>
✓ Asset bundle staged ...
✓ Asset bundle extracted ...
✓ WSO CLI installed /usr/bin/wso
✓ EULA acceptance recorded by the CLI
▓ Loading images <elapsed>
✓ Container images loaded and verified
-------------------------------------------------------------
Stage 3 of 7 - Initialize the cluster
-------------------------------------------------------------
✓ Cluster initialization cp-cluster / <size>
✓ Cluster inventory 5 nodes across 12 groups
✓ Control Plane profile generated defaults retained
-------------------------------------------------------------
Stage 4 of 7 - Validate the cluster
-------------------------------------------------------------
• Optional Control Plane precheck skipped
✓ Cluster inventory validated
-------------------------------------------------------------
Stage 5 of 7 - Deploy the Control Plane
-------------------------------------------------------------
▓ Control Plane deployment <elapsed>
✓ Control Plane deployed
✓ Platform health Vault, Consul, and Nomad healthy
-------------------------------------------------------------
Stage 6 of 7 - Deploy Access services
-------------------------------------------------------------
✓ Access profile written
✓ Access configuration synced to Vault and Consul
✓ <service-1> deployed
✓ <service-2> deployed
...
✓ <service-47> deployed
✓ Access services 47/47 · 100%
✓ Service readiness all services READY
-------------------------------------------------------------
Stage 7 of 7 - Create the tenant
-------------------------------------------------------------
▓ Tenant creation <elapsed>
✓ Tenant created successfully
Se sua conexão cair ou você interromper o assistente
O comando resume continua do último estágio de implantação concluído. O trabalho concluído que ainda for válido é ignorado, e as respostas do questionário salvas anteriormente não são solicitadas novamente.
- Durante o questionário: pressionar Ctrl+C e, em seguida, executar
resumerestaura as respostas que você já salvou. - Durante o monitoramento de um estágio de implantação protegido: pressionar Ctrl+C desconexa seu terminal. Ele não interrompe a implantação. Os estágios protegidos continuam em execução mesmo que sua sessão SSH seja desconectada.
Para verificar o andamento ou continuar em qualquer um dos casos, reconecte-se e execute:
sudo access-wizard status
sudo access-wizard resume
Criação e conclusão do locatário
Perto do final do Estágio 7, um link único para redefinição de senha é exibido na tela. Copie-o imediatamente: ele expira em 24 horas e não é gravado em nenhum arquivo de log. Digite CONTINUE depois de salvá-lo.
=============================================================
COPY THIS NOW - the link expires in 24 hours
=============================================================
Login URL https://<tenant-name>.<base-domain>
Username admin
Reset your password at:
<one-time-reset-link>
Se o SMTP tiver sido configurado durante o questionário, a interface de linha de comando da Omnissa solicitará de forma segura a senha da conta de serviço SMTP neste momento.
SMTP uses a secure password prompt from the Omnissa CLI.
Enter SMTP Password: ********
✓ SMTP configured
Quando a implantação for concluída, o assistente exibirá um resumo de conclusão com o tempo total de implantação, o URL do locatário, o nome de usuário do administrador, o nome do cluster e a contagem de nós. Se algum item opcional tiver sido ignorado durante o questionário, uma linha "Ainda pendente" listará o que deve ser configurado posteriormente.
---------------------------------------------------------------
Deployment complete
---------------------------------------------------------------
✔ All done - total time: <elapsed>
Tenant URL https://<tenant-name>.<base-domain>
Administrator admin
Cluster <cluster_name>
Nodes 3 Infrastructure, 2 Access
Still outstanding:
SMTP is not configured. Run: sudo access-wizard configure
PLATFORM ACCESS
From /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env
Nomad https://<nomad-ip>:4646
Consul https://<consul-ip>:8501
Vault https://<vault-ip>:8202
Administrative tokens are stored in the protected environment file:
/opt/wss/<cluster_name>/cp-cluster/cp-cluster.env (root-only, mode 600)
To display tokens securely:
sudo access-wizard show-tokens
Logs from this run are in: /opt/wss/.omnissa-wizard/logs/
Para resolução de problemas, os mesmos valores podem ser lidos diretamente do nó, em vez de por meio de show-tokens:
sudo cat /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env
Após a implantação
Verifique o status:
sudo access-wizard status
---------------------------------------------------------------
Progress
---------------------------------------------------------------
Cluster <cluster_name>
Tenant <tenant-name>.<base-domain>
done Prerequisite validation
done Working directory preparation
done Deployment asset preparation
done Workspace ONE configuration
done Cluster initialization
skipped SSH key configuration
done Cluster configuration
done Control Plane profile
skipped Control Plane precheck
done Cluster inventory validation
done Control Plane deployment
done Platform health validation
done Access profile preparation
done Access configuration synchronization
done Access services deployment
done Service readiness
done Tenant creation
done SMTP configuration
All phases complete.
Revele os tokens da plataforma (Nomad, Consul e Vault não são exibidos automaticamente após a implantação):
sudo access-wizard show-tokens
Requer um terminal interativo. Digite REVEAL quando solicitado.
Configure SMTP, NTP, NFS ou Cert-Proxy. O comando access-wizard configure é executado somente após a conclusão da implantação. O comando percorre todos os quatro itens de uma só vez, solicitando [y/N] para cada um. Responda n para manter uma configuração inalterada:
[root@ng-bootstrap wss]# access-wizard configure
Full session log: /opt/wss/.omnissa-wizard/logs/session-20260807-220226-configure.log
-------------------------------------------------------------
Optional configuration
-------------------------------------------------------------
Configure the optional settings you need. Answer no to leave a
setting unchanged and continue to the next one.
Configure SMTP? [y/N]: n
Configure NTP? [y/N]: n
Configure NFS? [y/N]: n
Configure Cert-Proxy (Mobile SSO for Android)? [y/N]: n
-------------------------------------------------------------
Configuration complete
-------------------------------------------------------------
SMTP unchanged
NTP unchanged
NFS unchanged
Cert-Proxy unchanged
Colete um pacote de suporte, caso a Omnissa solicite o envio de diagnóstico:
sudo access-wizard support-bundle
Isso grava um arquivo compactado com logs, configuração e detalhes do ambiente em /opt/wss/.omnissa-wizard/. Revise-o antes de enviar.
Comandos adicionais: access-wizard também fornece credentials, verify-control-plane, docs e uma opção de deploy --dry-run. Execute access-wizard --help para uso completo.
Se um serviço falhar durante a implantação
Se o Estágio 6 (Implantar serviços do Access) relatar que um serviço está com problema, recupere-o sem reiniciar toda a implantação:
-
Verifique em qual estágio ou serviço está travado:
sudo access-wizard status -
Decida como proceder com base no que o status mostra:
-
Se a implantação do Control Plane estiver
running, não tente retomar. Abra um tíquete de suporte no Suporte da Omnissa e anexe um pacote de suporte:sudo access-wizard support-bundle -
Se a implantação do Control Plane estiver
donee nada específico for indicado como com falha, prossiga com:sudo WIZ_CP_REDEPLOY=yes access-wizard resumeIsso retoma da validação de integridade, depois do perfil do Access e, em seguida, dos serviços do Access.
-
Se a implantação do Control Plane estiver em
donee a saída de status indicar um serviço do Access específico com falha (relatado como X/47), resolva esse serviço primeiro:-
Abra a UI do Nomad, localize o trabalho com falha e elimine-o (pare e remova, não apenas reinicie).
-
Reimplante apenas esse serviço do diretório de trabalho do cluster do nó Bootstrap:
cd /opt/wss/<cluster_name> wso services deploy -s <service-name>Nota: implante apenas o serviço que falhou durante o fluxo automatizado.
-
Assim que esse serviço for reimplantado com sucesso, retome o assistente:
sudo access-wizard resume
Lista de serviços implementados em ordem:
control-plane-logging host-logging telegraf-statsd telegraf-asset-server ingress ingress-gateway-route-reloader control-plane-backup client-side-load-balancer telegraf-uptime cp-ops-dispatch cp-ops-output-processor kafka kafka-monitoring postgres postgres-monitoring pgbouncer postgres-backup postgres-diff-backup postgres-operations postgres-operations-vacuum redis redis-monitoring opensearch coredns eecache nginx-http acs crypto cds token analytics saas federation authcontrol greenbox ws1notifications ws1ntfmanager skycap cas certproxy commchannel launcher ws1admin hubconsole mpsso nginx-stream usergroup -
-
Isso se aplica sempre que um serviço entra em um estado incorreto, não apenas durante a implantação inicial. O mesmo fluxo de recuperação funciona após uma implantação concluída ou durante um upgrade.
Esta página foi útil?