이 릴리스부터 access-wizard는 부트스트랩 노드 설정, 제어부 초기화, 제어부 배포, 액세스 및 인프라 서비스 배포 및 테넌트 생성 단계를 단일 단계별 명령으로 자동화합니다. 마법사는 짧은 질문 모음을 제시하고 구성 파일을 작성한 다음, 배포 단계를 순서대로 실행합니다. 이러한 단계를 개별적으로 수행하려는 경우 수동으로 Omnissa Access 배포를 참조하십시오.
참고: Access Wizard 26.07은 Omnissa Access 26.07.0.0의 그린필드 배포를 지원합니다. 기존 배포를 업데이트하고 이후 릴리스를 배포하는 것은 이 버전 범위를 벗어나는 것입니다.
필수 IP 주소, 인증서 및 기타 정보를 준비한 경우 질문에 응답하는 데 몇 분 정도 걸립니다. 다음에 수행되는 자동화된 배포에는 약 1.5~2시간이 걸립니다.
시작하기 전에
시작하기 전에 다음을 확인합니다.
- 1단계 - Omnissa Access 설치를 위한 가상 시스템 준비 및 2단계 - Omnissa Access 설치를 위한 가상 시스템 배포에서 부트스트랩, 인프라 및 Omnissa Access 가상 시스템이 배포되고 전원이 켜져 있습니다.
- 로드 밸런서는 X-Forwarded-For 헤더를 사용하도록 설정하고 포트 443에서 수신 대기하면서 로드 밸런서 또는 역방향 프록시를 사용하여 Omnissa Access에 대한 외부 액세스 사용에 설명된 대로 구성됩니다.
- 테넌트 FQDN에 대한 DNS(예:
tenant.example.com)가 로드 밸런서 IP 주소로 확인됩니다. - OVA 배포 중에 모든 노드에 설정된
configuser암호가 있습니다. 이 암호가 만료되었거나 재설정해야 하는 경우 Omnissa Access Control Plane 클러스터 노드 관리를 참조하십시오. - 자체 서명된(마법사가 생성할 수 있음) 또는 전체 체인 PEM 인증서 및 자체 CA에서 암호화되지 않은 개인 키를 일치시키는 TLS 인증서가 준비되었습니다.
참고:
- 마법사는 부트스트랩 노드의 디스크 공간 및 Docker 스토리지를 검증하고 다른 모든 노드에 대한 SSH 연결 및 인증을 확인합니다. 원격 노드의 CPU, RAM 또는 디스크 크기 조정을 독립적으로 확인하지 않음 - 시작하기 전에 1단계 - Omnissa Access 설치를 위해 가상 시스템 준비의 크기 조정 테이블에 대해 확인합니다.
- Access Wizard RPM은 디지털로 서명됩니다. 서명 확인( 아래의 서명 키 신뢰 및 RPM 확인 참조)은 다음 섹션의 SHA-256 체크섬 확인과는 별개입니다. 체크섬은 다운로드가 손상되지 않았음을 확인할 뿐, 해당 파일이 실제로 Omnissa에서 제공된 것인지는 확인하지 않습니다.
Access Wizard 다운로드 및 확인
절차:
-
Omnissa Customer Connect에 로그인하고 다음을 다운로드합니다.
- Omnissa Access 자산 번들(제어부 매니페스트 및 컨테이너 이미지가 포함된 ZIP 파일)
- Access Wizard RPM 번들 - RPM(),
.sha256체크섬 파일 및 Omnissa RPM 서명 공용 키(access-wizard-26.07.noarch.rpm``omnissa-linux-rpm-gpg-key.pub)의 세 가지 항목이 포함된 ZIP 파일입니다.
-
로컬 시스템에서 RPM 번들 압축을 풀거나 부트스트랩 노드에 복사한 후 다음 섹션을 참조하십시오.
unzip <wizard-bundle>.zip -
번들에 포함된
.sha256파일에 대해 RPM을 확인하고 게시된 체크섬에 따라 자산 번들을 확인합니다.sha256sum -c access-wizard-26.07.noarch.rpm.sha256 sha256sum <asset-bundle>.zip두 값이 일치하지 않으면 계속 진행하지 마십시오.
부트스트랩 노드에 파일 업로드
절차:
-
두 zip을 부트스트랩 노드에 복사합니다.
scp <wizard-bundle>.zip <asset-bundle>.zip \ configuser@<bootstrap-ip>:/home/configuser/ -
부트스트랩 노드에
configuser권한으로 연결하고 RPM 번들의 압축을 풉니다.ssh configuser@<bootstrap-ip> unzip <wizard-bundle>.zip이 절차의 나머지 부분에 대해
configuser권한으로 로그인된 상태를 유지합니다. 모든 후속 명령은 명시적sudo를 사용합니다.
서명 키를 신뢰하고 RPM 확인
절차:
-
Omnissa RPM 서명 공개 키를 가져옵니다(RPM 번들 압축을 푼 디렉토리에서 실행).
sudo rpm --import omnissa-linux-rpm-gpg-key.pub -
RPM 서명 및 무결성을 확인합니다.
sudo rpm -K access-wizard-26.07.noarch.rpm출력은 유효한 다이제스트 및 서명을 나타내야 합니다. 확인이 실패할 경우 RPM을 설치하지 마십시오.
RPM 설치
절차:
sudo dnf install -y access-wizard-26.07.noarch.rpm
설치된 패키지 ID는 access-wizard-26.07-1.noarch입니다.
설치 확인
절차:
sudo access-wizard --version
예상되는 출력:
access-wizard 26.07
단계별 배포 시작
절차:
sudo access-wizard deploy --asset-bundle /<path>/<asset-bundle>.zip
마법사는 6개의 질문 섹션(기본 정보, 테넌트, 인프라 노드, 액세스 노드, 인증서, 선택적 서비스)을 나열하는 시작 화면을 표시한 다음, 시작하려면 Enter 키를 누르라는 메시지를 표시합니다.
● 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.
섹션 1: 기본 정보
-
https://www.omnissa.com/general-terms/에서 EULA를 검토하고 수락합니다.============================================================= 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> -
마법사가 자동으로 찾은 자산 번들을 확인합니다. 마법사는 게시된 체크섬에 대한 무결성을 검증합니다.
------------------------------------------------------------- Asset bundle verification ------------------------------------------------------------- ✓ Asset integrity <verification-detail> -
클러스터 이름을 선택합니다. 그러면 작업 디렉토리 경로
/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 -
배포 크기(소형, 중간 또는 대형)를 선택합니다. 마법사는 각 옵션에 대한 노드 토폴리지를 표시합니다.
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 -
부트스트랩 노드의 감지된 IP 주소를 확인합니다.
------------------------------------------------------------- This node ------------------------------------------------------------- This looks like the Bootstrap node, with IP address <bootstrap-ip>. Is that right? [Y/n]: Y -
공유
configuser암호를 입력합니다. 마법사는 부트스트랩 노드에 대해 즉시 유효성을 검사합니다. 필요한 경우 Omnissa Access Control Plane 클러스터 노드 관리를 참조하여 이 암호가 재설정하십시오.------------------------------------------------------------- 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. -
클러스터가 다른 노드에 대해 인증하는 방법(방금 입력한 암호 또는 생성된 SSH 키 쌍)을 선택합니다.
-
암호
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
-
-
진행하는 배포에 해당하는 경우 로드 밸런서 IP 주소 및 X-Forwarded-For IP 주소를 입력합니다. 마법사는 포트 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.
섹션 2: 테넌트
테넌트 접두사 및 기본 도메인을 입력합니다. 사용자는 https://<tenant-name>.<base-domain>에서 배포에 도달합니다. 마법사는 FQDN이 로드 밸런서 IP로 확인되었는지 확인한 다음, 테넌트 관리자의 사용자 이름(기본값: admin), 이름, 성 및 이메일 주소를 묻습니다.
=============================================================
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.
섹션 3: 인프라 노드
3개의 인프라 노드 각각에 대한 IP 주소를 입력합니다. 마법사는 SSH 연결 가능성을 확인하고 입력할 때 각 노드에 대해 인증합니다. 중복된 주소는 거부됩니다.
=============================================================
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.
섹션 4: Access 노드
각 Access 노드의 IP 주소를 입력합니다(소형 또는 중형의 경우 2, 대형의 경우 3). 마법사는 각 연결 가능성 및 인증을 확인합니다.
=============================================================
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.
섹션 5: 인증서
테넌트 FQDN에 대해 Access에서 사용하는 한 TLS 인증서를 선택합니다.
- 자체 서명 — 배포 중에 자동으로 생성됩니다.
- 사용자 지정 — 자체 PEM 인증서 및 개인 키를 부트스트랩 노드에 업로드합니다. 마법사는 인증서 체인, 키 일치 및 테넌트 FQDN 범위가 유효한지 검사합니다.
-
자체 서명
============================================================= 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. -
사용자 지정
============================================================= 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.
섹션 6: 선택적 서비스
4가지 선택적 항목: SMTP, NTP, NFS 공유 스토리지 및 Android용 모바일 SSO를 위한 Cert-Proxy. 해당 항목을 나중에 지정하려면 [y/N] 프롬프트에 n(으)로 응답합니다. 액세스 마법사 구성으로 배포가 완료된 후 4개를 모두 다시 확인할 수 있습니다.
참고: 부트스트랩 노드는 입력한 NTP 서버에 대한 DNS 이름 확인 결과를 검증합니다.
=============================================================
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.
검토 및 확인
6개의 섹션이 모두 끝나면 마법사가 답변에 대한 전체 요약을 표시합니다.
=============================================================
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:
유효성 검사를 진행하려면 1을 선택하고, 다른 항목을 변경하려면 2를 선택하고, 배포하지 않고 종료하려면 3을 선택합니다.
Is everything above correct?
1) Yes, continue to validation
2) No, let me change something
3) Exit without deploying
Choose 1-3: 1
그러면 마법사는 최종 준비 상태 요약을 표시하고 배포를 시작하도록 요청합니다.
-------------------------------------------------------------
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:
배포 단계
마법사는 다음 7개의 단계를 자동으로 실행합니다. 진행률을 모니터링하려면 터미널 세션을 열어 두십시오.
| 준비 | 이름 | 수행되는 작업 |
|---|---|---|
| 1 | 모든 사전 요구 사항 검증 | 루트 권한, 필요한 명령, 노드 인증, OS 유효성 검사, 자산 번들 무결성, 디스크 공간, 로드 밸런서 검사 |
| 2 | 배포 자산 준비 | 작업 디렉토리, 자산 번들 스테이징 및 추출, CLI 설치, 컨테이너 이미지 로드 |
| 3 | 클러스터 초기화 | 클러스터 구성, SSH 키 분포(선택한 경우), 클러스터 인벤토리, 제어부 프로파일 |
| 4 | 클러스터 유효성 검사 | 구성 사전 검사, 인벤토리 유효성 검사 |
| 5 | 제어부 배포 | Vault, Consul, Nomad 및 플랫폼 서비스, 플랫폼 상태 검증 |
| 6 | Access 서비스 배포 | Access 프로파일, 구성 동기화, 모든 Access 애플리케이션 서비스, 서비스 준비 게이트 |
| 7 | 테넌트 생성 | 테넌트 생성, 재설정 링크 전달, SMTP 구성(선택한 경우) |
-------------------------------------------------------------
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
연결이 끊어지거나 마법사를 중단하는 경우
resume 명령은 마지막으로 중단했던 배포 단계에서 계속됩니다. 유효한 상태로 유지되는 완료된 작업을 건너뛰고 이전에 저장된 질문 답변은 다시 요청되지 않습니다.
- 질문에 답변하는 동안: Ctrl+C를 누른 다음,
resume을 실행 하면 이미 저장한 응답이 복원됩니다. - 보호된 배포 단계를 모니터링하는 동안: Ctrl+C를 누르면 터미널에서 분리됩니다. 배포가 중지됩니다. SSH 세션 연결이 끊어지더라도 보호된 단계가 계속 실행됩니다.
진행률을 확인하거나 두 경우 모두에서 계속 진행하려면 다시 연결하고 다음을 실행합니다.
sudo access-wizard status
sudo access-wizard resume
테넌트 생성 및 완료
7단계가 끝날 무렵, 일회용 암호 재설정 링크가 화면에 표시됩니다. 즉시 복사 — 24시간 후에 만료되며 로그 파일에 기록되지 않습니다. 저장한 후 CONTINUE를 입력합니다.
=============================================================
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>
질문 답변 중에 SMTP가 구성된 경우 Omnissa CLI는 이 시점에 SMTP 서비스 계정 암호를 묻는 메시지를 안전하게 표시합니다.
SMTP uses a secure password prompt from the Omnissa CLI.
Enter SMTP Password: ********
✓ SMTP configured
배포가 완료되면 마법사에 총 배포 시간, 테넌트 URL, 관리자 사용자 이름, 클러스터 이름 및 노드 수가 포함된 완료 요약이 표시됩니다. 질문에서 선택적 항목을 건너뛴 경우 "미해결" 줄에 나중에 구성할 항목이 나열됩니다.
---------------------------------------------------------------
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/
문제 해결을 위해 show-tokens를 통하지 않고 노드에서 직접 동일한 값을 읽을 수 있습니다.
sudo cat /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env
배포 후
상태 확인:
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.
플랫폼 토큰 표시(배포 후 Nomad, Consul, Vault가 자동으로 표시되지 않음):
sudo access-wizard show-tokens
대화형 터미널이 필요합니다. 메시지가 표시되면 REVEAL을 입력합니다.
SMTP, NTP, NFS 또는 Cert-Proxy 구성. access-wizard configure 명령은 배포가 완료된 후에만 실행됩니다. 이 명령은 네 가지 항목을 한 번에 차례대로 진행하며 항목마다 [y/N]을 지정하라는 메시지를 표시합니다. 설정을 변경하지 않고 그대로 두려면 n으로 답변합니다.
[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
Omnissa가 진단을 보내도록 요청하는 경우 지원 번들을 수집합니다.
sudo access-wizard support-bundle
이렇게 하면 로그, 구성 및 환경 세부 정보의 수정된 아카이브가 /opt/wss/.omnissa-wizard/에 기록됩니다. 보내기 전에 검토하십시오.
추가 명령: access-wizard는 credentials, verify-control-plane, docs 및 deploy --dry-run 옵션도 제공합니다. 전체 사용법을 확인하려면 access-wizard --help를 실행합니다.
배포 중에 서비스가 실패하는 경우
6단계(Access 서비스 배포)가 서비스를 비정상으로 보고하는 경우 전체 배포를 다시 시작하지 않고 복구합니다.
-
중단된 단계 또는 서비스를 확인합니다.
sudo access-wizard status -
상태에 표시되는 내용에 따라 진행 방법을 결정합니다.
-
제어부 배포가
running인 경우 재개를 시도하지 마십시오. 대신 Omnissa 지원을 통해 지원 티켓을 열고 지원 번들을 연결합니다.sudo access-wizard support-bundle -
제어부 배포가
done이고 실패로 확인된 구체적인 항목이 없는 경우 다음을 수행하여 재개합니다.sudo WIZ_CP_REDEPLOY=yes access-wizard resume그러면 상태 유효성 검사, Access 프로파일, Access 서비스 순서로 진행됩니다.
-
제어부 배포가
done이고 상태 출력에 실패한 특정 Access 서비스(X/47로 보고됨)가 명시되면 먼저 해당 서비스를 확인합니다.-
Nomad UI를 열고 실패한 작업을 찾은 후 제거합니다(다시 시작하는 것뿐만 아니라 중지하고 제거).
-
부트스트랩 노드의 클러스터 작업 디렉토리에서 하나의 서비스만 다시 배포합니다.
cd /opt/wss/<cluster_name> wso services deploy -s <service-name>참고: 자동화된 흐름 중에 실패한 서비스만 배포합니다.
-
해당 서비스가 성공적으로 다시 배포되면 마법사를 재개합니다.
sudo access-wizard resume
순서대로 배포되는 서비스 목록:
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 -
-
이 문제는 초기 배포 도중 뿐만 아니라 서비스가 잘못된 상태가 될 때마다 적용됩니다. 배포가 완료된 후 또는 업그레이드 중에 동일한 복구 흐름이 작동합니다.
이 페이지가 도움이 되었나요?