Désinstaller complètement Sophos Protection for Linux

La suppression complète de Sophos Protection for Linux (SPL) comprend trois opérations distinctes : désinstaller localement l’agent avec son script intégré, vérifier ou remplacer la protection du serveur, puis seulement supprimer l’enregistrement obsolète dans Sophos Fusion (anciennement Sophos Central). Une suppression dans Central ne désinstalle pas SPL du serveur.

De même, Actions > Manage software > Uninstall current protection ne désinstalle pas complètement SPL en local : cette action supprime les composants de protection, mais laisse en place Sophos Core Agent, chargé de la communication et de la gestion des stratégies. Pour une suppression complète, utiliser le programme de désinstallation local (Sophos : Computers and servers).

Cette procédure concerne l’agent serveur Sophos Protection for Linux. Elle ne s’applique ni à Sophos Endpoint sous Windows ou macOS, ni à Sophos Anti-Virus for Linux (SAV), ni au Sophos Linux Sensor distinct.

Procédure en bref

Confirmer la fenêtre de maintenance, l’accès root, le chemin d’installation et la protection de remplacement.
Conserver l’état SPL local et les données Central requises.
Exécuter uninstall.sh depuis l’installation SPL existante en tant que root.
Utiliser rmdir uniquement pour les répertoires cgroup vides indiqués par Sophos.
Vérifier la suppression locale et la protection de remplacement.
Ensuite seulement, supprimer l’enregistrement Central obsolète ou réinstaller SPL avec un programme d’installation actuel du tenant.

Avant la désinstallation

Prévoir une fenêtre de maintenance et surveiller les workloads dépendants.
Disposer d’un shell root ou de sudo.
Arrêter les outils de déploiement, de configuration et les Gold Images susceptibles de réinstaller SPL.
Conserver les alertes, l’état Health et les données d’investigation avant toute suppression Central.
Identifier le chemin réel. Par défaut, SPL se trouve dans /opt/sophos-spl ; adapter tous les chemins pour une installation avec --install-dir.
Définir la protection après suppression. La désinstallation ne réactive pas un logiciel tiers supprimé ou remplacé.

Consigner l’état initial :

sudo systemctl status sophos-spl
sudo test -x /opt/sophos-spl/bin/uninstall.sh && printf 'SPL uninstaller found\n'

La première commande peut montrer un service actif. La seconde doit confirmer un programme exécutable. En cas d’échec, ne pas copier uninstall.sh depuis un autre hôte ni supprimer manuellement des fichiers ; clarifier d’abord le chemin et l’état de l’agent.

Tamper Protection et B-02 : Sophos documente Tamper Protection pour Windows et macOS, pas pour Sophos Protection for Linux. Cette procédure Linux ne contient donc aucun mot de passe Central et ne promet aucun contournement sans mot de passe après expiration de licence ou suppression du terminal. Ne pas transposer le comportement Windows ou macOS à Linux. La voie prise en charge reste le programme SPL local exécuté avec les droits root.

Exécuter le programme SPL pris en charge

Pour le chemin par défaut, Sophos documente le programme intégré suivant :

cd /opt/sophos-spl/bin
sudo ./uninstall.sh

Pour une installation personnalisée, aller dans <BASE-INSTALLATION>/sophos-spl/bin. <BASE-INSTALLATION> est exactement la base passée à --install-dir ; ne pas transférer le script de /opt vers une autre installation.

Conserver le code de sortie et toute la sortie du terminal. La fin du processus ne prouve pas à elle seule le succès.

Traiter sûrement les répertoires cgroup restants

Sophos indique exactement ces quatre commandes après la désinstallation :

sudo rmdir /sys/fs/cgroup/sophos.slice
sudo rmdir /sys/fs/cgroup/cpuacct/sophos.slice
sudo rmdir /sys/fs/cgroup/cpu/sophos.slice
sudo rmdir /sys/fs/cgroup/memory/sophos.slice

rmdir ne supprime que les répertoires vides. Si un chemin n’existe pas, il n’y a rien à supprimer à cet emplacement ; son absence ne prouve pas que la désinstallation est complète. Selon la distribution et la version de cgroup, les quatre chemins ne sont pas tous applicables. Si rmdir signale un répertoire non vide ou toute autre erreur inattendue (par exemple un chemin cgroup monté ou en cours d’utilisation), conserver le message exact et l’état du système, puis escalader comme indiqué ci-dessous. Ne pas poursuivre avec rm -rf, des jokers récursifs ou des commandes improvisées de nettoyage des services, paquets ou du noyau.

Vérifier la suppression et la protection de remplacement

Effectuer au minimum ces contrôles :

sudo systemctl status sophos-spl
sudo test ! -e /opt/sophos-spl/bin/uninstall.sh
sudo test ! -d /sys/fs/cgroup/sophos.slice
sudo test ! -d /sys/fs/cgroup/cpuacct/sophos.slice
sudo test ! -d /sys/fs/cgroup/cpu/sophos.slice
sudo test ! -d /sys/fs/cgroup/memory/sophos.slice

Adapter la deuxième ligne pour un chemin personnalisé. Le service sophos-spl ne doit plus être actif, le programme de désinstallation doit avoir disparu du chemin utilisé et les répertoires cgroup cités ne doivent plus exister. L’absence de certains chemins inapplicables à la version de cgroup ne prouve pas la réussite de la désinstallation et ne neutralise ni un échec du programme ni une erreur rmdir inattendue. Un dossier résiduel hors de ces chemins de vérification documentés ne prouve ni une protection active ni l’autorisation de le supprimer manuellement.

Vérifier également :

Que la protection de remplacement prévue est active, à jour et signale un état sain.
Que les services métier et la supervision du serveur fonctionnent après l’intervention.
Qu’aucun déploiement ne réinstalle SPL de manière imprévue.
Que le serveur n’envoie plus de nouvelle activité SPL à Central après un délai raisonnable.

Supprimer ensuite seulement le terminal de Sophos Fusion

Si le serveur est définitivement mis hors service ou remplacé par un autre objet appareil, ne nettoyer son enregistrement qu’après la validation de la suppression locale. Arrêt obligatoire avant toute suppression d’appareil : rechercher les avertissements de doublons et les autres entrées portant la même identité d’agent ; un nom d’hôte unique ne suffit pas. En particulier pour les serveurs clonés ou les Golden Images, clarifier d’abord l’identité et l’historique du clonage. Sophos avertit que supprimer un appareil ayant des doublons peut empêcher ceux-ci de communiquer ou de se réinscrire. En présence d’un doublon ou d’une identité incertaine, ne pas supprimer : clarifier la correspondance et escalader au support Sophos (suppression d’appareil, événements de doublons, procédure Golden Image Linux). La désinscription d’une image modèle relève d’une procédure d’imagerie distincte et ne remplace pas uninstall.sh.

Ouvrir My Environment > Computers & Servers.
Une fois les contrôles de doublons et d’identité réussis, sélectionner le serveur Linux auquel l’enregistrement correspond sans ambiguïté.
Conserver les alertes et données d’investigation nécessaires.
Choisir Actions > Delete device et confirmer la suppression.
Vérifier que l’enregistrement quitte la liste active et n’est pas recréé par un agent ou un déploiement restant.

Pour une réparation temporaire ou une réinstallation planifiée, ne pas supprimer prématurément l’enregistrement ; conserver son état pour le diagnostic.

En cas d’échec

`uninstall.sh` manque ou ne démarre pas

Revérifier chemin, droits et variante SPL. Avec un chemin personnalisé, le script se trouve sous sophos-spl/bin. Ne pas emprunter de script ni supprimer au hasard fichiers, paquets, utilisateurs ou services.

Le service continue ou SPL se manifeste à nouveau

Examiner code de sortie et sortie complète, puis contrôler déploiement, gestion de configuration, scripts de démarrage et Gold Images. Ne pas supprimer plusieurs fois l’enregistrement Central tant qu’un agent ou job peut être actif.

Une commande cgroup renvoie une erreur inattendue

Si un répertoire n’est pas vide ou si rmdir renvoie une autre erreur inattendue, ne pas forcer une suppression récursive. Relever l’état des processus et des montages, le message d’erreur exact, la distribution, le noyau, la version de cgroup, la version SPL, le chemin d’installation et l’heure. Transmettre ces éléments avec la sortie de uninstall.sh au support Sophos. Ne pas improviser de commandes supplémentaires pour nettoyer les résidus.

Point d’escalade

Si l’agent reste actif, si le programme échoue ou si l’état se contredit, ne pas considérer le serveur comme retiré. Assurer la protection de remplacement et, en cas de lacune de protection, isoler le serveur conformément à sa propre procédure d’incident. Fournir au support Sophos la distribution et sa version, l’architecture, le noyau, la version SPL, le chemin personnalisé ou par défaut, la commande exacte, le code de sortie, la sortie complète, l’horodatage, l’état du service et le message d’erreur cgroup exact.

Uniquement si SPL est encore installé et si l’outil concerné est disponible : relever éventuellement l’état avec /opt/sophos-spl/bin/sophosctl status (Endpoint Self Help ; adapter le chemin pour une installation personnalisée) ou utiliser Sophos Diagnostic Utility (SDU) pour recueillir les journaux SPL et système. Ces diagnostics sont facultatifs : ils ne conditionnent pas la réussite de la suppression et ne remplacent pas le journal du programme de désinstallation (Sophos : dépannage SPL).

Réinstallation et retour arrière

La désinstallation n’a pas de rollback automatique. Pour restaurer SPL, utiliser un Linux Server Installer actuel et lié au tenant depuis My Environment > Installers, puis suivre Installer et déployer Sophos Protection for Linux. Ne pas réparer avec un ancien programme, un dossier d’agent copié ou le uninstall.sh supprimé.

La restauration n’est terminée que lorsque le service local fonctionne, que le serveur apparaît dans Central avec l’identité attendue, reçoit les composants et stratégies serveur prévus, et que la protection requise est manifestement active. Jusque-là, la demande de changement reste ouverte.