Utilizzare questo articolo per determinare l'azione da intraprendere in caso di problemi di compatibilità tra un prodotto Trellix e un software di terze parti.
Lavoriamo con tutte le terze parti per comprendere la causa principale del problema e laddove necessario risolverlo con una soluzione o una soluzione alternativa del prodotto. Tuttavia, è possibile che il cliente richieda l'apertura di un ticket al fornitore di terze parti se le indagini determinano che la causa del problema
non è il prodotto.
Inoltre, tutte le parti potrebbero dover partecipare a una conferenza telefonica per trovare una soluzione.
Attenersi alla seguente procedura:
- Verificare la presenza di un problema noto tra il software di terze parti e il prodotto. Quando viene a conoscenza di un problema di compatibilità, il problema viene documentato nella Knowledge Base. L'articolo della Knowledge Base viene aggiornato con qualsiasi soluzione alternativa nota o correzione del prodotto, se disponibile. Se la causa del problema è il software di terze parti, la soluzione alternativa o la soluzione fornita dal fornitore del software di terze parti viene documenta.
- Eseguire la risoluzione dei problemi per individuare la causa del problema:
- Se le indagini determinano che la causa del problema è il nostro prodotto, Assistenza tecnica aprire un difetto rispetto a quel prodotto. Verrà fornita una soluzione alternativa o una correzione del prodotto.
- Se le indagini in corso determinano che la causa del problema non è il prodotto, procedere al passaggio 3.
- Contattare il fornitore del software di terze parti e aprire una ticket.
Il primo risponditore di un problema di compatibilità del software deve essere il fornitore il cui software si comporta in modo imprevisto. Il primo risponditore esegue il debug del comportamento imprevisto del software. Si verifica uno dei seguenti eventi:
Informazioni importanti sul software proprietario e di terze parti: Le procedure precedenti sono una necessità tecnica perché nel software proprietario closed-source, i simboli privati necessari per eseguire il debug delle applicazioni sono proprietà intellettuale limitata dai fornitori. Se questi simboli privati fossero divulgati pubblicamente, il software potrebbe essere decodificato. Non siamo proprietari o non abbiamo accesso a questi simboli proprietari o codice sorgente.
Glossario:
- Software di debug (o "debugger"): Il software utilizzato da uno sviluppatore che consente di determinare un punto di errore utilizzando simboli o codice sorgente.
- Codice sorgente chiuso: Il codice originale che comprende il processo o il driver; protetto e non disponibile a livello privato.
- Codice open source: Il codice originale che comprende il processo o il driver; disponibile pubblicamente.
- Simboli privati: File utilizzati da un debugger per visualizzare i nomi delle funzioni e dei file di codice sorgente; protetto e non disponibile a livello privato.
- Simboli pubblici: File utilizzati da un debugger per visualizzare solo i nomi delle funzioni; disponibile pubblicamente.
Società come le Red Hat sono open source e rilasciano il proprio codice sorgente e i simboli privati. Altre aziende, come Microsoft e Trellix, sono fonti chiuse e rilasciano simboli pubblici al massimo. Esistono simboli privati e codice sorgente chiuso per proteggere la proprietà intellettuale di un vendor dall'essere disponibile pubblicamente e consentire alle vendite di software di rimanere una parte del loro portafoglio entrate.
Microsoft è quasi sempre un'origine chiusa. Microsoft rilascia simboli pubblici in modo che i fornitori di terze parti possano visualizzare tutti i nomi delle funzioni Microsoft richiamati durante il debug del software di terze parti. Tuttavia, i nomi delle funzioni sono tutti elementi che i fornitori di terze parti possono determinare Microsoft codice. Microsoft utilizzare il proprio codice sorgente chiuso e i simboli privati per determinare perché il codice ha avuto un comportamento analogo. Si tratta di un limite nel mondo dell'interoperabilità del software closed-source.