NetWorker: Identifiser klienter som krever sletting av nodeinformasjon "Feil-SSL-protokollfeil"

I enkelte situasjoner kan NetWorker-serverens daemon.raw kan oversvømmes med tilkoblingsfeil for generisk sikkerhetstjeneste (GSS) mellom to NetWorker-systemer:

MM/DD/YYYY HH:MM:SS  5 13 9 3635926784 26586 0 NSR_HOSTNAME nsrexecd SSL critical Unable to complete SSL handshake with nsrexecd on host 'CLIENT_NAME': An error occurred as a result of an SSL protocol failure. To complete this request, ensure that the certificate attributes for CLIENT_NAME and NSR_NAME match in the NSRLA database on each host. 

Eller

MM/DD/YYYY HH:mm:SS 5 12 10 11256 2900 0 NSR_NAME nsrexecd GSS critical An authentication request from CLIENT_NAME was denied. The 'NSR peer information' provided did not match the one stored by NSR_NAME. To accept this request, delete the 'NSR peer information' resource with the following attributes from NSR_NAME's NSRLA database: name: CLIENT_NAME; NW instance ID: CLIENT_ID; peer hostname: CLIENT_NAME 
MM/DD/YYYY HH:mm:SS 0 0 0 6384 6380 0 NSR_NAME nsrd NSR info Authentication Warning: Conflicting NSR peer information resources detected for host 'CLIENT_NAME'. Please check server daemon log for more information. 

Kjør som root- eller administratorledetekst fra NetWorker-serveren:

nsradmin -C -y -p nsrexecd "nsr peer information"

Se: NetWorker: Hvordan fjerne NSR-peer-informasjonsavvik automatisk ved hjelp av nsradmin -C

Denne kommandoen kontrollerer hver nodesertifikatressurs i NetWorker-serverens nsrladb og forsøker å rette det opp. Denne operasjonen må også kjøres på klientene som rapporterer dette problemet. Dette kan forekomme for mange klienter, og det blir vanskelig å isolere alle de forskjellige vertene som krever korreksjon.

Følgende prosess kan brukes til å bestemme hvilke systemer som krever kjøring: nsradmin -C -y eller kan kreve manuell sletting av informasjon fra likesinnede.

Linux-verter:

1. Gjengi daemon.raw:

nsr_render_log -S "1 weeks ago" /nsr/logs/daemon.raw > /nsr/logs/daemon.out 2<&1

2. Opprett en fil som bare inneholder tilkoblingsfeilene for GSS-godkjenning:

cat /nsr/logs/daemon.out | grep "SSL handshake" > GSS_error.out

Eller:

cat /nsr/logs/daemon.out | grep "NSR peer information" > GSS_error.out

3. Opprett en fil som bare inneholder klientnavnene fra GSS-utdatafilen:

cat GSS_error.out | awk {'print $24'} | sort > client.out

Denne kommandoen bruker Linux awk og skrive ut kommandoer for å skrive ut bare column som inneholder klientnavnet fra den fullstendige feilmeldingen om SSL-tilkobling. Avhengig av filter number brukt, endrer du utskriftsnummeret for å skrive ut klientnavnene riktig hvis eksemplet ovenfor ikke returnerer de forventede resultatene.

4. Se gjennom filen ved hjelp av den unike kommandoen for å bare mate ut én forekomst av hver av klientene som rapporterer dette problemet:

cat client.out | uniq

Eksempel:

[root@nsrserver logs]# nsr_render_log daemon.raw > daemon.out 2<&1
[root@nsrserver logs]# cat daemon.out | grep "SSL handshake" > GSS_error.out                
[root@nsrserver logs]# cat GSS_error.out | awk {'print $24'} | sort > client.out
[root@nsrserver logs]# cat client.out | uniq                              
'client1':
'client2':
'client3':
'client4':
'client5':
'client6':

Ovennevnte vertsnavn er endret; nå, i stedet for hundrevis av oppføringer i daemon.raw, rapporterer bare én oppføring for hver klient denne virkemåten.

5. Koble til klientsystemene som rapporteres ved hjelp av SSH eller Remote Desktop Protocol (RDP), og bruk en rot-/administrativ ledetekst for å kjøre:

nsradmin -C -y -p nsrexecd "nsr peer information"

Hvis du kjører denne kommandoen på både serveren og klienten, bør du kontrollere at nsrladb På hvert system finnes riktig nodesertifikatinformasjon. Hvis det oppdages et avvik, slettes sertifikatet, og neste tilkoblingsforsøk mellom serveren og klienten skal generere et nytt.

Den nsradmin Kommandoen viser hvilke verter som ikke har samsvar, og hvilken handling som ble utført i utdataene.

Manuell sletting av nodeinformasjon er beskrevet i artikkelen NetWorker: Korrigere inkonsekvent NSR-nodeinformasjon

6. Utdatafilene kan slettes når det ikke lenger er behov for dem:

rm -rf filename

Windows-verter:

1. Åpne en Windows PowerShell-ledetekst som administrator.
2. Endre kataloger til NetWorker-loggkatalogen:

cd "C:\Program Files\EMC NetWorker\nsr\logs"

Eksemplet forutsetter at standard installasjonsplassering brukes. Hvis du installerte NetWorker på et annet sted, endrer du kommandoen tilsvarende.

3. Gjengi daemon.raw:

nsr_render_log -S "1 weeks ago" daemon.raw > daemon.out 

4. Opprett en fil som bare inneholder tilkoblingsfeilene for GSS-godkjenning:

elect-String -Path .\daemon.out -pattern "SSL handshake" > GSS_error.out

Eller:

Select-String -Path .\daemon.out -pattern "NSR peer information" > GSS_error.out

5. Generer utdata som viser unike systemer som rapporterer GSS-godkjenningsfeilene:

Get-Content .\GSS_error.out | %{ $_.Split(' ')[9]; } | Sort | Unique

PS C:\Program Files\EMC NetWorker\nsr\logs> Get-Content .\GSS_error.out | %{ $_.Split(' ')[9]; } | Sort | Unique
13120
13932
2808
2828
2856
2900
2920
2956
5716
6088
6328
6380
6772
6852
8196
9388
networker-mc.emclab.local
redhat.emclab.local
winsrvr.emclab.local

6. Koble til klientsystemene som rapporteres ved hjelp av SSH eller RDP, og bruk en rot-/administrasjonsledetekst for å kjøre:

nsradmin -C -y -p nsrexecd "nsr peer information"

Hvis du kjører denne kommandoen på både serveren og klienten, bør du kontrollere at nsrladb På hvert system finnes riktig nodesertifikatinformasjon. Hvis det oppdages et avvik, slettes sertifikatet, og neste tilkoblingsforsøk mellom serveren og klienten skal generere et nytt.

Den nsradmin Kommandoen viser hvilke verter som ikke har samsvar, og hvilken handling som ble utført i utdataene.

Manuell sletting av nodeinformasjon er beskrevet i artikkelen NetWorker: Korrigere inkonsekvent NSR-nodeinformasjon

7. Utdatafilene kan slettes når det ikke lenger er behov for dem.