View a markdown version of this page

Risoluzione dei problemi - AWS Trasformazione

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi

Verifica della connettività degli strumenti di rilevamento a vCenter

Se riscontri errori di configurazione dei moduli VMware, segui questi passaggi per verificare la connettività:

Accedi allo strumento di rilevamento VM
  • Log-in allo strumento di rilevamento VM, aprire Remote Console in vCenter

    • Nome utente: discovery

    • Password: password

Test della connettività vCenter
  1. Test dell'accesso all'API vCenter:

    curl -v --insecure -u <username>:<password> https://<vcenter-ip-or-hostname>:443/mob
  2. Risultato di successo previsto:

    [ec2-user@discoverytool ~]$ curl -v --insecure -u <user>:<password> https://vcsa/mob > tmp.txt % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.168.2.125:443... * Connected to vcsa (192.168.2.125) port 443 (#0) ... </xml> * Connection #0 to host vcsa left intact
Certificato SSL di prova
  1. Eseguire il comando:

    openssl s_client -showcerts -servername <hostname> -connect <hostname>:443
  2. Risultato di successo previsto:

    • Dovrebbe mostrare i dettagli del certificato vSphere

    • Verifica la SSL/TLS connettività sulla porta 443

    [ec2-user@discoverytool ~]$ openssl s_client -showcerts -servername vcsa -connect vcsa:443 CONNECTED(00000003) depth=0 CN = vcsa.onpremsim.env, C = US verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = vcsa.onpremsim.env, C = US verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=vcsa.onpremsim.env/C=US i:/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- --- Server certificate subject=/CN=vcsa.onpremsim.env/C=US issuer=/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering ---

Risoluzione dei problemi WinRM

Se riscontri problemi di connettività con WinRM, segui questi passaggi per testare la connessione. Questi passaggi si applicano anche ai problemi di Hyper-V connettività, poiché lo strumento di rilevamento utilizza WinRM per comunicare con gli host. Hyper-V

Verifica la connettività WinRM di base utilizzando le porte 5985 (HTTP) e 5986 (HTTPS). Dobbiamo assicurarci che la connettività funzioni sulla porta 5986 (HTTPS)

# Check WinRM listener configuration winrm enumerate winrm/config/listener # Note: Replace <HOST> with the target computer's hostname or IP address. Adjust the username and password as needed. # Test WinRM connection on port 5985 (HTTP) $cred = Get-Credential Test-WSMan -Computer <HOST> -Authentication Negotiate -Credential $cred -Port 5985 # Test WinRM connection on port 5986 (HTTPS) Test-WSMan -Computer <HOST> -Authentication Negotiate -Credential $cred -Port 5986

Se i test precedenti falliscono, prova a stabilire una PowerShell sessione con la convalida dei certificati disabilitata:

$cred = Get-Credential $so = New-PsSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck Enter-PSSession -ComputerName <HOST> -Credential $cred -Port 5985 -SessionOption $so

Risoluzione dei problemi Kerberos

Se riscontri errori di autenticazione Kerberos durante la raccolta di dati dai server Windows, utilizza le seguenti sezioni per diagnosticare e risolvere i problemi più comuni.

Verifica i requisiti di rete

Prima di risolvere i problemi di autenticazione Kerberos, verifica che lo strumento di rilevamento possa raggiungere gli endpoint di rete richiesti.

Per verificare i requisiti di rete per Kerberos
  1. Verifica la risoluzione DNS sul controller di dominio. Esegui il comando seguente dalla macchina virtuale dello strumento di rilevamento:

    nslookup dc01.example.com

    In alternativa, è possibile utilizzare dig:

    dig dc01.example.com

    Se la risoluzione DNS fallisce, verifica che lo strumento di rilevamento VM sia configurato per utilizzare un server DNS in grado di risolvere il dominio Active Directory. Verifica /etc/resolv.conf e conferma che le voci del nameserver puntino ai server DNS del tuo dominio.

  2. Verifica la connettività al Key Distribution Center (KDC) sulla porta 88. Esegui il comando seguente:

    nc -zv dc01.example.com 88

    Output previsto:

    Connection to dc01.example.com 88 port [tcp/kerberos] succeeded!

    Se la connessione fallisce, verifica che nessuna regola del firewall blocchi il traffico dalla macchina virtuale dello strumento di rilevamento al controller di dominio sulla porta 88.

  3. Verifica la connettività ai server Windows di destinazione sulle porte WinRM. Esegui i comandi seguenti:

    nc -zv <windows-server> 5985 nc -zv <windows-server> 5986

    Se la connessione fallisce, verifica che WinRM sia abilitato sul server di destinazione e che le regole del firewall consentano il traffico in entrata sulle porte 5985 e 5986.

Problemi comuni relativi a Kerberos

Di seguito sono riportati i problemi comuni di Kerberos e le relative soluzioni.

Errori di distinzione tra mai

Sintomo: durante l'autenticazione viene visualizzato l'errore «Server non trovato nel database Kerberos».

Questo errore si verifica in genere quando il nome dell'area di autenticazione Kerberos non è in maiuscolo. I realm Kerberos devono essere specificati in lettere maiuscole nel file. krb5.conf Ad esempio, utilizza EXAMPLE.COM anziché example.com.

Prevenzione del blocco dell'account

Lo strumento di rilevamento utilizza un meccanismo di backoff per impedire il blocco degli account dovuto a ripetuti tentativi di autenticazione falliti. Se il tuo account di servizio viene bloccato, puoi reimpostare il processo di raccolta interrompendo e quindi avviando il modulo di raccolta tramite l'interfaccia utente web dello strumento di rilevamento all'indirizzo. https://<discovery-tool-vm-ip>:5000

kinit fallisce dalla CLI

La tabella seguente elenca gli kinit errori più comuni e le relative soluzioni.

Errore Causa Soluzione
Impossibile trovare KDC for realm Il nome host o l'indirizzo IP del KDC non sono raggiungibili oppure il realm non è configurato in. krb5.conf Verifica che il krb5.conf file contenga il nome host e il realm KDC corretti. Conferma la risoluzione DNS e la connettività di rete al KDC sulla porta 88.
Preautenticazione non riuscita La password per l'account di servizio non è corretta. Verifica la password e riprova. Se l'account è bloccato, sbloccalo in Active Directory prima di riprovare.
Client non trovato nel database Kerberos Il nome principale non corrisponde a nessun account in Active Directory. Verifica che il nome principale corrisponda esattamente al nome dell'account, maiuscole e minuscole. Usa il formato username@REALM con il realm in maiuscolo.
Impossibile risolvere l'indirizzo di rete per KDC Il DNS non è in grado di risolvere il nome host KDC. Verifica la configurazione DNS in. /etc/resolv.conf Verifica che il server DNS sia in grado di risolvere il nome host KDC. Esegui il test con o. nslookup dig

La raccolta fallisce nonostante il successo di kinit

Se kinit riesce ma la raccolta dei dati continua a fallire, controlla quanto segue:

  1. Verifica che il nome principale utilizzato per la raccolta corrisponda kinit esattamente al maiuscolo/minuscolo utilizzato durante.

  2. Verificate che l'account di servizio disponga delle autorizzazioni richieste sui server di destinazione.

  3. Verificare che WinRM sia abilitato sui server di destinazione.

  4. Verifica che il nome host utilizzato per la raccolta corrisponda al nome host registrato in Active Directory.

Kerberos funziona per alcuni server ma non per altri

Se l'autenticazione Kerberos riesce per alcuni server ma fallisce per altri, esamina le seguenti aree:

Se i tuoi server si estendono su più domini Active Directory, configura una credenziale Kerberos separata per ogni dominio. Assicurati che il /etc/krb5.conf file includa voci per tutti i reami. Ogni dominio richiede la propria credenziale con il principale correttousername@REALM.

Confronta la configurazione WinRM su un server funzionante con un server guasto. Esegui il comando seguente su ogni server:

winrm get winrm/config

Verifica la connettività con Remote Desktop per isolare il problema. Lo strumento di rilevamento utilizza il formatousername@DOMAIN, mentre Remote Desktop utilizza il formatoDOMAIN\username.

Verificate che l'account di servizio sia membro del gruppo Administrators locale sul server in cui si verifica l'errore. Esegui il comando seguente sul server di destinazione:

net localgroup Administrators

WMI richiede i privilegi di amministratore locale per accedere alle informazioni del sistema operativo. La raccolta SQL Server richiede inoltre che l'account di servizio disponga dell'accesso di amministratore locale sul server di destinazione.

Elenco di controllo per la configurazione Kerberos

Utilizza la seguente lista di controllo per verificare la configurazione di Kerberos prima di iniziare la raccolta dei dati.

  • Il krb5.conf file esiste nella macchina virtuale dello strumento di rilevamento.

  • Il nome del realm è in maiuscolo in. krb5.conf

  • L'esecuzione kinit con l'account del servizio riesce senza errori.

  • Running klist mostra un ticket valido e non scaduto.

  • Il nome principale corrisponde esattamente al nome dell'account di Active Directory.

  • La risoluzione DNS funziona per il nome host KDC.

  • La connettività di rete al KDC sulla porta 88 è confermata.

  • La connettività di rete ai server Windows di destinazione sulle porte 5985 e 5986 è confermata.

  • (Multi-domain) Ogni dominio Active Directory ha le proprie credenziali configurate nello strumento di rilevamento [realms] e krb5.conf contiene [domain_realm] voci per tutti i domini.

Risoluzione dei problemi del database Orac

Per diagnosticare problemi di raccolta del database Oracle, come dati mancanti o errori, controlla quanto segue.

Connessione rifiutata o timeout

Sintomo: lo stato della raccolta Oracle mostra un errore di connessione per un server.

Per risolvere questo problema, controlla quanto segue:

  • Verifica che il listener Oracle sia in esecuzione sull'host di destinazione: lsnrctl status

  • Verifica la connettività di rete dallo strumento di rilevamento all'host Oracle sulla porta 1521 (o sulla porta personalizzata): nc -zv <oracle-host> 1521

  • Verifica che le regole del firewall consentano le connessioni in entrata sulla porta del listener Oracle.

  • Verifica il nome del servizio eseguendolo lsnrctl services sull'host Oracle. Se il nome del servizio non è corretto, il listener Oracle rifiuta la connessione.

Errori di autenticazione () ORA-01017

Sintomo: la raccolta non riesce a causa di un errore di nome utente o password non validi.

Per risolvere questo problema, controlla quanto segue:

  • Verifica che l'account del servizio Oracle esista e non sia bloccato: SELECT account_status FROM dba_users WHERE username = 'DISCOVERY_USER';

  • Verifica che la password sia corretta collegandoti manualmente: sqlplus discovery_user/<password>@<host>:1521/<service_name>

  • Se l'account è bloccato, sbloccalo: ALTER USER discovery_user ACCOUNT UNLOCK;

Privilegi insufficienti () ORA-01031

Sintomo: la connessione riesce ma la raccolta restituisce dati incompleti.

Per risolvere questo problema, controlla quanto segue:

  • Verifica che SELECT_CATALOG_ROLE sia concesso: SELECT * FROM dba_role_privs WHERE grantee = 'DISCOVERY_USER';

  • Concedi il ruolo richiesto se manca: GRANT SELECT_CATALOG_ROLE TO discovery_user;

Le credenziali manuali mostrano errori ma la connessione automatica funziona

Quando si aggiunge manualmente una credenziale a un server, lo strumento di rilevamento non ritorna se la connessione fallisce. Verifica che la porta e il nome del servizio configurati sulla credenziale corrispondano al listener Oracle su quel server specifico. Se il server ha una porta o un nome di servizio non standard, aggiorna di conseguenza la configurazione delle credenziali.

OS-level fallback che non rileva Oracle

Se non sono configurate credenziali del database e il OS-level fallback non rileva Oracle:

  • Verificate che le credenziali del sistema operativo SSH o WinRM siano configurate e funzionanti per il server (controllate lo stato della raccolta delle metriche del sistema operativo).

  • Per gli host Linux, verifica che /etc/oratab esistano o che i processi Oracle process monitor () pmon siano in esecuzione.

  • Per gli host Windows, verifica che esistano voci del registro Oracle HKLM\SOFTWARE\Oracle o che oracle.exe i processi siano in esecuzione.

Risoluzione dei problemi SNMP

Accedi allo strumento di rilevamento VM
  • Log-in allo strumento di rilevamento VM, aprire Remote Console in vCenter

    • Nome utente: discovery

    • Password: password

Installare gli strumenti SNMP (se necessario)
  • sudo yum install net-snmp-utils -y

Verifica la connessione SNMP ai server Linux
  1. snmptable -v 2c -c <COMMUNITY_STRING> <REMOTE_SERVER_IP> .1.3.6.1.2.1.6.13.1

  2. Esempio:

    #SNMPv2c: snmptable -v 2c -c public 192.168.1.100 .1.3.6.1.2.1.6.13.1 #SNMPv3 (with authentication): snmptable -v 3 -u <username> -a MD5 -A <auth_password> 192.168.1.100 .1.3.6.1.2.1.6.13.1 #SNMPv3 (with privacy): snmptable -v 3 -u <username> -a MD5 -A <auth_password> -x DES -X <priv_password> 192.168.1.100 .1.3.6.1.2.1.6.13.1

Errori di raccolta in rete

è necessario un terminale per leggere la password

Errore:

ss command failed on <host>: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper sudo: a password is required

Il comando ss richiede la password dell'utente. L'utente ssh configurato deve appartenere al gruppo sudoers ed essere configurato con sudo senza password per il comando. ss/netstat Per configurare sudo senza password:

  1. Crea un nuovo file sudoers:

    sudo vi -f /etc/sudoers.d/<username>
  2. Aggiungi la riga:

    <username> ALL=(ALL) NOPASSWD: /usr/sbin/ss, /usr/bin/netstat
  3. Dopo questa modifica, l'esecuzione sudo ss -tnap e sudo netstat -tnap dovrebbe essere eseguita senza richiedere una password

La raccolta di rete è stata eseguita senza sudo

Se viene visualizzato il seguente avviso nella pagina Inventario scoperto:

Network collection ran without sudo. Process-level connection data may be missing.

Questo avviso indica che l'account utente SSH non dispone dell'accesso sudo sul server di destinazione. Senza sudo, lo strumento di rilevamento può comunque raccogliere i dati delle connessioni di rete, ma non può determinare a quale processo appartiene ciascuna connessione. Per raccogliere dati di connessione completi a livello di processo, assicurati che l'utente SSH disponga dell'accesso sudo sul server di destinazione.

Errori di raccolta delle metriche del sistema operativo

UUID del server mancante per i server Linux

Se lo strumento di rilevamento non è in grado di raccogliere l'UUID del server (visualizzato come vuoto o mancante) per i server Linux, verifica che le credenziali SSH configurate per tali server abbiano i privilegi sudo. Lo strumento utilizza dmidecode per leggere l'UUID del server. Se non dmidecode è installato, lo strumento torna alla lettura/sys/class/dmi/id/product_uuid, che richiede anche l'accesso sudo. Senza sudo, nessuno dei due metodi può recuperare l'UUID.

Risoluzione: assicurati che l'account utente SSH fornito allo strumento di rilevamento disponga dell'accesso sudo sui server Linux di destinazione.

Problemi di accesso nell'inventario Discovered

Se viene visualizzato un messaggio nello stato della raccolta sul server, ad esempio Credenziali mancanti o Accesso negato:

  1. Seleziona il server nella tabella dei server rilevati.

  2. Scegli Gestisci credenziali di accesso Puoi scegliere di:

    1. Seleziona credenziali alternative dal menu a discesa Seleziona credenziali.

    2. Seleziona Usa nuove credenziali e fornisci nuove credenziali.

  3. Save (Salva).

Lo strumento di rilevamento riprova la connessione dopo aver salvato le modifiche.

Risoluzione dei problemi di autenticazione tramite chiave SSH

Test della connettività delle chiavi SSH dallo strumento di rilevamento

Se l'autenticazione con chiave SSH fallisce, verifica la connettività dallo strumento di rilevamento al server di destinazione:

  1. Accedere allo strumento di rilevamento (tramite console vSphere o SSH sull'host Linux).

  2. Verifica la connettività SSH utilizzando la tua chiave privata:

    ssh -i /path/to/private_key -o StrictHostKeyChecking=no <username>@<target_ip>
  3. Se la connessione riesce, il problema riguarda il modo in cui la chiave è stata caricata nello strumento di rilevamento. Re-upload inserisci la chiave e verifica che il nome utente corrisponda.

  4. Se la connessione fallisce, controlla il messaggio di errore nella tabella seguente.

Messaggio di errore Causa Risoluzione
Permission denied (publickey) La chiave pubblica non è nel authorized_keys file del server di destinazione o il nome utente è sbagliato. Aggiungi la chiave pubblica ~/.ssh/authorized_keys al server di destinazione per l'utente corretto. Verifica le autorizzazioni dei file:chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys.
Connection timed out after 20s La porta 22 non è raggiungibile dallo strumento di rilevamento. Verificate che la porta 22 sia aperta tra lo strumento di rilevamento e il server di destinazione. Controlla i firewall e i gruppi di sicurezza.
Connection refused Il servizio SSH non è in esecuzione sul server di destinazione. Avvia il servizio SSH:. sudo systemctl start sshd
Invalid SSH key for credential 'name' Il formato della chiave non è supportato, i dati chiave sono danneggiati o la passphrase è mancante o errata. Verifica che il formato della chiave sia RSA, ECDSA o Ed25519 in formato PEM, OpenSSH o PKCS #8. Se la chiave è crittografata, assicurati che la passphrase sia corretta.

Risoluzione dei problemi del programma di installazione Linux

La porta 5000 è già in uso

Sintomo: il servizio Discovery Tool non si avvia dopo l'installazione.

Risoluzione: identifica e interrompi il processo utilizzando la porta 5000:

sudo ss -tlnp | grep :5000

Interrompi il processo in conflitto, quindi riavvia lo strumento di rilevamento:

sudo ./AWS-Transform-discovery-tool.sh start

Messaggi di errore comuni

Questa tabella descrive i messaggi di errore più comuni e le relative spiegazioni:

Messaggio Location (Ubicazione) Spiegazione
È già stata creata una password Crea una pagina con password Condizione di gara in cui due utenti creano password contemporaneamente; aggiorna
Esportazione non riuscita Pagina dell'inventario Riprova o invia i registri
È già in corso una raccolta su richiesta Pagina dell'inventario Condizione di gara quando due utenti avviano le raccolte manuali contemporaneamente; riprova al termine della raccolta manuale corrente
Command timed out after 60s Stato della raccolta sul server Un comando sul server di destinazione non è stato completato entro 60 secondi. Ciò può verificarsi su server con carichi elevati. Riprova la raccolta o esamina il carico del server di destinazione.
Una o più credenziali contengono UUID sconosciuti Pagina di accesso al sistema operativo Condizione valida quando due utenti modificano le credenziali del sistema operativo contemporaneamente; riprova
Password non valida Sign-in pagina Password errata per l'accesso; contatta l'amministratore o contattaci
La tua sessione è scaduta. Effettua nuovamente il login. Sign-in pagina La sessione è scaduta, è necessario effettuare nuovamente il login
Si è verificato un errore interno Diverse pagine Riprova o invia i log