Sophos Protection for Linux installieren und ausrollen

Wichtige Produktgrenze: Die Sophos-Onboarding-Seite nennt den Abschnitt zwar Deployment to Linux innerhalb des Endpoint-Leitfadens. Ihre Linux-Links führen jedoch zu Server Protection und Sophos Protection for Linux (SPL) in Sophos Fusion (ehemals Sophos Central). Linux erhält damit nicht den in den benachbarten Kapiteln beschriebenen Windows-/macOS-Endpoint-Installer, sondern einen eigenen Linux-Server-Agenten, eigene Richtlinien, Anforderungen, Release Notes und Installationsverfahren.

Der übergreifende Ablauf von Tenant-Vorbereitung bis Betrieb steht im Endpoint-Onboarding-Pfad. Dieser Artikel übernimmt darin ausschliesslich den Linux-Server-Track.

Für einen einzelnen Linux-Server wählt man unter My Environment > Installers zuerst den Schutzmodus: Download Linux Server Installer für vollständigen Malware-Schutz oder Download XDR Sensor Linux Server Installer für den XDR Sensor ohne eigenen Malware-Schutz. Den für den vorgesehenen Tenant und Modus geladenen Installer SophosSetup.sh macht man ausführbar und startet ihn mit Root-Rechten. Für mehrere Systeme verwendet man diesen Installer in einer kontrollierten Softwareverteilung und prüft zuerst mit --test. Soll SPL bereits im VM-Template enthalten sein, muss der dokumentierte Linux-Gold-Image-Prozess verwendet werden, damit jeder Klon eine eigene Geräteidentität erhält. Für Auto-Scaling-, Load-Balancing- oder grosse VM-Umgebungen empfiehlt Sophos, diesen Ansatz zu prüfen.

Vor dem ersten Pilotgerät

Die Installation wird erst freigegeben, wenn folgende Punkte geprüft sind:

• Lizenz und gewünschter Schutzumfang: Unter Server Protection stehen zwei getrennte Linux-Downloads zur Wahl. Der XDR Sensor setzt eine XDR-Lizenz voraus und schützt laut Sophos nicht selbst vor Bedrohungen; dafür muss ein Drittanbieter-Schutz vorhanden sein. Gewünschten Modus und verfügbare Lizenz vor dem Download abgleichen.
• Unterstützte Plattform: Distribution, Version, Architektur und Kernel müssen zur aktuellen SPL-Supportmatrix passen. Sophos führt die jeweils getesteten Plattformen und Systemanforderungen in den Release Notes. Für nicht gelistete, gehärtete, minimale, benutzerdefinierte oder Legacy-Varianten gelten besondere Supportgrenzen. Für immutable Distributionen wird SPL nicht erzwungen; Sophos verweist dafür auf den separaten Sophos Linux Sensor.
• Grundanforderungen: Beim Inhaltsreview vom 14. September 2026 verlangten die SPL Release Notes 2,5 GB freien Speicherplatz, 2 GB freien Arbeitsspeicher, x86_64 oder ARM64, ein laufendes unterstütztes systemd, Bash und glibc 2.17 oder neuer beziehungsweise 2.18 oder neuer auf ARM64. ARM64 benötigte zusätzlich Kernel 5.3 oder neuer. Für den Installer musste curl vorhanden sein; das AV-Plugin benötigte setcap aus libcap2-bin, libcap oder libcap-progs. Diese datierte Prüfbasis ersetzt nicht die aktuelle Freigabeprüfung.
• Netzwerkzugriff: Das Gerät muss während der Installation und danach Sophos Fusion erreichen können. DNS, HTTPS, Proxy, TLS Inspection sowie gegebenenfalls Message Relay und Update Cache werden aus jedem vorgesehenen Servernetz nach den Netzwerk- und Proxy-Anforderungen getestet.
• Bestehender Schutz: Sophos Anti-Virus for Linux kann nicht parallel zu SPL betrieben werden. SAV muss vorher entfernt oder beim Installer-Aufruf mit --uninstall-sav migriert werden. Bei einem reinen XDR Sensor muss dagegen ein Drittanbieter-Schutz aktiv bleiben, weil der Sensor selbst keinen Malware-Schutz bietet. Für vollständigen SPL-Malware-Schutz wird eine mögliche Parallelinstallation anderer Virenschutzprodukte vor dem Pilot separat anhand der Herstellerfreigaben bewertet.
• Rollout-Vertrag: Zielgruppe, Central-Gruppe, Produktumfang, Pilotgrösse, Stop-Kriterien, Wartungsfenster und Rückweg werden vor dem Start festgehalten.

Release-, Plattform- und Netzwerkangaben pflegen

Dieser Artikel ist die interne Prüfbasis für die Linux-spezifischen Anforderungen. Der zuständige Owner kontrolliert monatlich sowie vor jedem Pilot und jeder Rollout-Welle die aktuellen SPL Release Notes und die Distributions- und Kernel-Supportmatrix im Sophos-Portal. Im Change werden Prüfdatum, prüfende Person, Release-Stand, Distribution, Version, Architektur, Kernel, Mindestressourcen, Abweichungen und Freigabeentscheid festgehalten. Weichen aktuelle Angaben von der oben datierten Basis ab, werden Pilotkriterien und dieser Artikel vor der nächsten Welle aktualisiert; alte Werte gelten nicht als Freigabe.

Die verlinkte Netzwerk-Anleitung besitzt den gemeinsamen Allowlist- und Proxy-Prozess, einschliesslich Linux- und lizenzabhängiger Ziele. Für Softwarepakete, gestaffelte Aktualisierungen, Update Cache und Message Relay gilt ergänzend Sophos Endpoint Updates, Cache und Message Relay. Der Linux-Pilot prüft trotzdem den tatsächlichen Pfad und die installierte SPL-Version aus jedem vorgesehenen Servernetz.

Dateisysteme und Ressourcen vorab prüfen

Nur bei vollständigem Malware-Schutz mit installiertem Produkt antivirus: SPL scannt und quarantänisiert Dateien nur auf ausdrücklich unterstützten Dateisystemen zuverlässig. Beim Quellenabgleich vom 20. September 2026 nannte Sophos bfs, btrfs, cifs, devtmpfs, ecryptfs, ext2, ext3, ext4, fuse, fuseblk, iso9660, jfs, jfs2, msdos, nfs, nfs4, overlay, squashfs, tmpfs, udf, vfat, xfs und zfs. Vor jeder Welle wird diese Liste mit der aktuellen SPL-Dokumentation abgeglichen. Auf dem AV-Pilotgerät zeigt folgender Befehl alle eingehängten Ziele und Typen:

findmnt -rn -o TARGET,FSTYPE

Im AV-Modus werden nicht nur / und der Installationspfad geprüft, sondern alle Mounts mit geschäftsrelevanten Daten, Containern, Netzwerkfreigaben oder geplanten Scanzielen. Ein nicht gelistetes Dateisystem gilt nicht als freigegeben, nur weil ein erster Test unauffällig bleibt. Sophos empfiehlt, solche Dateisysteme vom Scanning auszunehmen; Dateisysteme mit bekannten Problemen schliesst das AV-Plugin automatisch aus und protokolliert dies in soapd.log. Für einen reinen XDR Sensor sind Scanziele, Quarantäne und dieses AV-Log keine Abnahmekriterien.

SPL verwaltet CPU- und Speichergrenzen über Linux-cgroups. Die Standardkonfiguration ist laut Sophos für die meisten Umgebungen geeignet. Deshalb werden vor dem Pilot keine pauschalen Grenzwerte gesetzt. Ist eine Begrenzung betrieblich nötig, werden zunächst Lastprofil und Anwendungstoleranz gemessen und danach die auf dem Gerät installierte Datei /opt/sophos-spl/base/etc/cgroup-resource-limits-README.txt gelesen. Sie ist massgeblich, weil Optionen, Komponenten und gültige Werte sich ändern können. Eigene Werte gehören in /opt/sophos-spl/base/etc/cgroup-limits.conf; CPU-Werte sind Prozente der gesamten CPU und benötigen %, Speicherwerte können je nach Option MB oder Prozent sein. Werte ausserhalb des unterstützten Bereichs verwirft SPL zugunsten des Standardwerts. Dieser Artikel gibt deshalb bewusst keine universellen Zahlen vor.

Nach Installation beziehungsweise Änderung gelten die folgenden Prüfungen entsprechend dem tatsächlich installierten Modus:

1. Nur mit antivirus: findmnt zeigt für jedes vorgesehene Scanziel einen aktuell unterstützten Typ.
2. Bei angepassten cgroup-Grenzen: /opt/sophos-spl/logs/base/watchdog.log bestätigt die auf die tatsächlich installierten Komponenten angewendete Konfiguration und enthält keinen Konfigurationsfehler.
3. Bei angepassten cgroup-Grenzen: Das Systemjournal enthält keine durch die SPL-cgroup ausgelösten Prozessabbrüche. Da nicht jedes Linux-System Journaldaten über einen Neustart bewahrt, wird die persistente Journal-Aufbewahrung nach der lokalen Betriebsrichtlinie eingerichtet, wenn die Fehlerhistorie erhalten bleiben muss.

Einzelinstallation über Sophos Fusion

1. In Sophos Fusion zu My Environment > Installers wechseln.
2. Im Bereich Server Protection den passenden Linux-Download wählen: Für vollständigen Malware-Schutz Download Linux Server Installer, für einen reinen XDR Sensor Download XDR Sensor Linux Server Installer (XDR-Lizenz und aktiver Drittanbieter-Schutz erforderlich). Nicht den Windows- oder macOS-Endpoint-Installer verwenden. Der separat angebotene Sophos Linux Sensor (SLS) ist nicht der SPL-XDR-Sensor.
3. SophosSetup.sh über einen zugriffsgeschützten Weg auf den vorgesehenen Linux-Server übertragen.
4. In das Downloadverzeichnis wechseln und die Ausführungsberechtigung setzen:

chmod +x SophosSetup.sh

5. Zuerst die Vorabprüfungen ohne Installation ausführen:

sudo ./SophosSetup.sh --test

6. Sind die Prüfungen erfolgreich, den Installer starten:

sudo ./SophosSetup.sh

Ohne --install-dir installiert SPL nach /opt/sophos-spl/. Der erfolgreiche Abschluss des Shell-Prozesses ist noch keine Rollout-Abnahme; Registrierung, tatsächlich installierte Komponenten, passende Richtlinien und Health werden anschliessend in Central und lokal geprüft. Die unten beschriebenen AV-Prüfungen gelten nicht für einen reinen XDR Sensor.

Installer direkt auf dem Server herunterladen

Für einen manuellen Download per Shell kopiert man in Sophos Fusion die Linkadresse des zuvor gewählten Linux-Installers (vollständiger Schutz oder XDR Sensor) und verwendet sie als Platzhalter im folgenden Befehl:

wget '<LINUX-INSTALLER-LINK>' -O SophosSetup.sh
chmod +x SophosSetup.sh
sudo ./SophosSetup.sh --test
sudo ./SophosSetup.sh

<LINUX-INSTALLER-LINK> wird durch die im eigenen Tenant für den gewählten Modus kopierte Adresse ersetzt. Die URL und die heruntergeladene Datei gehören nicht in öffentliche Skriptrepositories, Tickets oder frei lesbare Shares. Für wiederholbare Deployments wird das Installationsartefakt über die geschützte Paket- oder Secret-Verteilung der eigenen Plattform bereitgestellt.

Mehrere Linux-Systeme per Skript ausrollen

Ein Massenrollout beginnt mit wenigen repräsentativen Servern. Unterschiede bei Distribution, Kernel, Architektur, Hardening, Proxyweg, Standort, Workload und vorhandener Security-Software gehören in den Pilot. Erst nach bestandener Abnahme folgt die nächste begrenzte Welle.

Das folgende Skript ist ausschliesslich ein Beispiel für vollständigen Malware-Schutz mit zusätzlich lizenziertem XDR, nicht für einen reinen XDR Sensor. Es verwendet den dafür geladenen Linux Server Installer, ordnet das Gerät der Untergruppe LinuxServers\Pilot zu und fordert die Komponenten antivirus und xdr an:

#!/usr/bin/env bash
set -euo pipefail

if (( EUID != 0 )); then
  printf 'Dieses Rollout-Skript muss als root ausgeführt werden.\n' >&2
  exit 1
fi

installer='/var/tmp/SophosSetup.sh'
chmod 700 "$installer"

"$installer" --test
"$installer" \
  --group='LinuxServers\Pilot' \
  --products=antivirus,xdr \
  --tag=Rollout:wave-0 \
  --tag=ManagedBy:automation

Der Gruppenpfad ist an die eigene Central-Struktur anzupassen. Existiert die angegebene Gruppe oder Untergruppe noch nicht, erstellt der Installer sie. Deshalb wird der Pfad vor dem Rollout exakt geprüft: Ein Tippfehler kann eine unerwünschte neue Gruppe erzeugen. Bei --products werden nicht lizenzierte Produkte nicht installiert; erlaubt sind laut aktueller CLI-Seite antivirus, mdr und xdr. Mehrere --tag=<key>:<value>-Argumente ergänzen Geräte-Tags. Bei doppelten Schlüsseln zeigt Central nur den zuletzt übergebenen Wert.

set -euo pipefail sorgt in diesem Beispiel dafür, dass das Skript nach einer fehlgeschlagenen Vorprüfung oder Installation nicht still als erfolgreich weiterläuft. Die Softwareverteilung muss den echten Exitstatus übernehmen und darf fehlgeschlagene Hosts nicht endlos erneut installieren. Da Sophos auf der CLI-Seite keine dauerhafte Tabelle numerischer Exitcodes veröffentlicht, entscheidet nicht eine erfundene Code-Zuordnung, sondern die kombinierte lokale und Central-Abnahme.

Wichtige Installer-Optionen

Umgebungsvariablen stehen vor, Kommandozeilenoptionen nach dem Installer-Aufruf.

UIDs und GIDs der von SPL angelegten Konten und Gruppen lassen sich mit --user-ids-to-configure und --group-ids-to-configure vorgeben. Diese Optionen werden nur eingesetzt, wenn die lokale Identity- oder Hardening-Vorgabe feste IDs verlangt; Sophos begrenzt ihre Wirkung ausdrücklich auf die dokumentierten SPL-Konten und -Gruppen.

Bei --install-dir=<basis> liegt SPL unter <basis>/sophos-spl. Alle folgenden Log-, Versions-, Registrierungs- und Uninstall-Pfade sind entsprechend anzupassen; die im Artikel gezeigten /opt/sophos-spl/...-Pfade gelten für die Standardinstallation. AV-Plugin-Pfade gelten zudem nur für Hosts mit installiertem Produkt antivirus.

Message Relay und Update Cache vorgeben

Normalerweise enthält SophosSetup.sh die in Central konfigurierten Relays und Caches. Der Installer ordnet sie anhand der numerischen Nähe zur Geräte-IP und verwendet den nächstgelegenen erreichbaren Dienst; wenn keiner erreichbar ist, kontaktiert er Central direkt. Für die Installation lässt sich die Auswahl explizit überschreiben:

sudo ./SophosSetup.sh \
  --message-relays=192.0.2.10:8190 \
  --update-caches=192.0.2.10:8191

192.0.2.10 ist eine Dokumentationsadresse und muss ersetzt werden. Sophos nennt Port 8190 für Message Relay und 8191 für Update Cache. Mit none wird für die jeweilige Option die direkte Central-Verbindung erzwungen. Der Override gilt für die Installation; danach verwendet der Agent wieder die nächstgelegenen konfigurierten Dienste, sofern man das Gerät nicht in Central manuell zuweist.

Gold Image für virtuelle Linux-Systeme

Ein installiertes und registriertes Linux-System darf nicht unverändert geklont werden. Vor dem Speichern des Templates wird die Gold-Image-VM in Sophos Fusion deregistriert. Jeder daraus gestartete Klon registriert sich danach automatisch mit einer eigenen Identität, sobald er startet und das Netzwerk erreicht.

1. Betriebssystem und Anwendungen der Master-VM vollständig vorbereiten.
2. Unter My Environment > Installers den zum vorgesehenen Schutzmodus passenden Linux Server Installer beziehungsweise XDR Sensor Linux Server Installer herunterladen.
3. SPL wie oben beschrieben installieren und den Zustand prüfen.
4. In das Registrierungsverzeichnis wechseln und die Master-VM deregistrieren:

cd /opt/sophos-spl/base/bin/
sudo ./registerCentral --deregister

5. Die VM sofort herunterfahren und das Image im ausgeschalteten Zustand speichern.
6. Die Master-VM nach der Deregistrierung nicht wieder starten. Ein Neustart registriert sie erneut; dann muss man sie vor dem Speichern nochmals deregistrieren.
7. Mindestens zwei Klone aus dem gespeicherten Image starten und prüfen, ob beide als getrennte Geräte in Central erscheinen.

Bei einem mit --install-dir geänderten Installationsort liegt sophos-spl unter dem angegebenen Pfad. Der Gold-Image-Befehl muss dann aus dem entsprechenden base/bin-Verzeichnis dieser Installation ausgeführt werden.

Installation abnehmen

Ein Pilot gilt erst als bestanden, wenn alle folgenden Kontrollen stimmen:

1. Unter My Products > Server > Servers erscheint für jeden Host genau das erwartete Geräteobjekt. Auf der Server-Detailseite sind Health, letzte Aktivität und installierte Komponenten plausibel.
2. Das Gerät liegt in der vorgesehenen Gruppe und erhält die für die tatsächlich installierten Komponenten vorgesehenen Server-Richtlinien. Bei vollständigem Malware-Schutz gehört dazu die wirksame Server Threat Protection Policy; bei Update-Richtlinien greift die erste passende Richtlinie.
3. Der Dienst läuft lokal:

sudo systemctl status sophos-spl

4. Nur bei installiertem Produkt antivirus: Die in Central angezeigte Server-Protection-Version stimmt mit der lokal gemeldeten Version überein:

sudo cat /opt/sophos-spl/plugins/av/VERSION.ini

Sophos nennt genau diese AV-Plugin-Datei zum Versionsvergleich. Bei einem reinen XDR Sensor wird sie nicht vorausgesetzt: Stattdessen auf der Server-Detailseite die tatsächlich installierten Komponenten, deren angezeigte Versionen, Health und letzte Aktivität mit dem gewählten Sensor-Modus abgleichen und lokal die Verbindung zu Sophos Fusion im zur installierten Version passenden MCS-/Management-Log prüfen: /opt/sophos-spl/logs/base/sophosspl/management.log oder bei LTS-Paketen gegebenenfalls die älteren Logs mcsrouter.log und sophos_managementagent.log. Lognamen und Pfad am installierten Paket prüfen; aus der blossen Anwesenheit oder Abwesenheit eines Logs oder AV-Pfads nicht auf die Sensorfunktion schliessen.

5. Nur bei installiertem Produkt antivirus: Für den EICAR-On-Access-Test müssen in der wirksamen Server Threat Protection Policy sowohl Real-time scanning - Local files and network shares als auch Enable scan for Server Protection for Linux Agent aktiviert sein; die Linux-spezifische Einstellung ist standardmässig ausgeschaltet. Danach wird die Erkennung in /opt/sophos-spl/plugins/av/log/av.log und auf der Server-Summary-Seite geprüft. Ein reiner XDR Sensor bietet weder diese Malware-Erkennung noch On-Demand-Scans; stattdessen den weiterhin aktiven Drittanbieter-Malware-Schutz separat nach dessen dokumentiertem Verfahren prüfen.

Die breite Welle wird gestoppt, wenn Geräte fehlen, doppelt erscheinen, ungesund bleiben, nicht die erwarteten Komponenten oder Policies erhalten oder geschäftskritische Workloads beeinträchtigt werden.

Rollout stoppen, zurückrollen oder entfernen

Rollback bedeutet zuerst, die Verteilung anzuhalten. Neue Zielzuweisungen und automatische Wiederholungen werden gestoppt, die betroffene Welle wird abgegrenzt und der letzte funktionierende VM-, Paket- oder Konfigurationsstand bleibt erhalten. Eine Deinstallation stellt entfernte oder ersetzte Drittanbieter-Schutzsoftware nicht automatisch wieder her.

Das vollständige Verfahren für lokale Entfernung, cgroup-Bereinigung, Prüfung, Umgang mit dem Central-Geräteobjekt und Wiederherstellung beschreibt Sophos Protection for Linux vollständig deinstallieren. Die dort dokumentierten Entfernungsbefehle werden nicht in einen Installations- oder Rollout-Job kopiert.

Tamper Protection ist für Sophos Protection for Linux nicht verfügbar und daher für diesen Rollback nicht anwendbar. Vor Abschluss des Changes werden dennoch verbleibende Server-Policies geprüft, der vorgesehene Schutz wiederhergestellt und der Umgang mit dem Central-Geräteobjekt festgelegt.

Troubleshooting nach Symptom

--test oder die Installation schlägt fehl

Den exakten Befehl, die Distribution, den Kernel, die Architektur und die Ausgabe sichern. Der Thin Installer startet bei erkanntem Installationsfehler automatisch die Sophos Diagnostic Utility (SDU) und legt ein sophos_diagnose.tgz im Verzeichnis des Thin Installers ab. Dieses Archiv enthält Installationslogs und Systeminformationen für Sophos Support.

Nur auf Anforderung von Sophos Support oder für eine kontrollierte Reproduktion ausführen: Der folgende Befehl startet den Installer erneut, aktiviert Shell-Debug-Ausgabe und bewahrt das temporäre Installationsverzeichnis auf.

sudo OVERRIDE_INSTALLER_CLEANUP=1 \
  DEBUG_THIN_INSTALLER=1 \
  bash -x ./SophosSetup.sh 2>&1 | tee install.log

OVERRIDE_INSTALLER_CLEANUP=1 bewahrt das temporäre Verzeichnis /tmp/SophosCentralInstall_<uuid> auf. Logs können Hostnamen, interne Pfade und Netzwerkdetails enthalten und werden vor einer Weitergabe geprüft.

/tmp ist mit noexec eingebunden

Nicht /tmp dauerhaft lockern. Einen geeigneten ausführbaren temporären Pfad anlegen und nur für den Installer mit TMPDIR setzen:

sudo TMPDIR=/var/tmp ./SophosSetup.sh --test
sudo TMPDIR=/var/tmp ./SophosSetup.sh

TMPDIR ändert nur die temporäre Ablage, nicht /opt/sophos-spl als Standard-Installationsziel.

Gerät erscheint nicht in Sophos Fusion

Zuerst DNS, TCP 443, Proxy, TLS Inspection und die aktuelle Domain-Allowlist prüfen. Danach im zur installierten Version passenden MCS-/Management-Log nach dem gewählten Verbindungsweg und einer erfolgreichen Verbindung suchen: /opt/sophos-spl/logs/base/sophosspl/management.log oder bei LTS-Paketen gegebenenfalls die älteren Logs mcsrouter.log und sophos_managementagent.log. Lognamen und Pfad am installierten Paket prüfen. Sophos zeigt im aktuellen management.log beispielsweise Successful connection via environment proxy und Connection method: Proxy.

Wenn ein noch nicht verwaltetes Linux-Gerät die Central-Proxykonfiguration nicht beziehen kann, dokumentiert Sophos als Bootstrap-Lösung eine Datei mit http_proxy=https://<PROXY_ADDRESS>:<PROXY_PORT>: auf Debian-basierten Systemen unter /etc/default/sophos-spl, auf RHEL, CentOS und Amazon Linux unter /etc/sysconfig/sophos-spl. Danach folgen:

sudo systemctl restart sophos-spl
sudo systemctl status sophos-spl

Anschliessend wird das zur installierten Version passende MCS-/Management-Log kontrolliert (bei LTS gegebenenfalls mcsrouter.log und sophos_managementagent.log).

Vollständiger Malware-Schutz ist installiert, aber Real-Time Scanning arbeitet nicht

Nur bei installiertem Produkt antivirus: In My Products > Server > Policies die wirksame Threat Protection Policy öffnen. Sowohl Real-time scanning - Local files and network shares als auch Enable scan for Server Protection for Linux Agent müssen aktiviert sein. Lokal nennt Sophos die Policy-Dateien /opt/sophos-spl/base/mcs/policy/CORC_policy.xml und /opt/sophos-spl/plugins/av/var/on_access_policy.json sowie das Log /opt/sophos-spl/plugins/av/log/soapd.log für die Diagnose. Für einen reinen XDR Sensor ist dies kein Fehlerbild; dessen Malware-Schutz muss vom Drittanbieter kommen.

Benutzerdefinierter Installationspfad scheitert mit SELinux Enforcing

Nicht mit --notest oder global deaktiviertem SELinux umgehen. Das neue Basisverzeichnis darf kein Symlink sein und noch kein Unterverzeichnis sophos-spl enthalten. Nach dem Erstellen wird der SELinux-Kontext von /opt auf den neuen Pfad übertragen:

sudo semanage fcontext -a -e /opt <PFAD_ZUM_NEUEN_INSTALLATIONSVERZEICHNIS>

Danach wird der Installer mit dem geprüften --install-dir gestartet. Fehlt semanage, wird zuerst das zur Distribution passende SELinux-Verwaltungspaket installiert; die Sicherheitskontrolle wird nicht deaktiviert.

Ein AV-Scanziel wird nicht gescannt oder Prozesse werden beendet

Nur bei installiertem Produkt antivirus: Für ein fehlendes Scanziel zuerst Typ und Mountpunkt mit findmnt -rn -o TARGET,FSTYPE prüfen. In /opt/sophos-spl/plugins/av/log/soapd.log nach is not supported and will be excluded from scanning suchen. Ein automatisch ausgeschlossenes oder nicht dokumentiertes Dateisystem wird nicht durch --notest erzwungen. Das Scanziel bleibt ausgeschlossen, bis ein aktuell unterstützter Typ verwendet oder Sophos Support die konkrete Konfiguration bestätigt.

Bei unerwarteten Prozessabbrüchen zuerst /opt/sophos-spl/logs/base/watchdog.log und anschliessend das Kernel-Journal prüfen:

sudo journalctl -k -b

Meldungen zu oom-kill, Memory cgroup out of memory oder verworfenen cgroup-Werten werden zusammen mit der wirksamen cgroup-limits.conf und der Last zum Fehlerzeitpunkt gesichert. Nicht blind einen höheren oder niedrigeren Zahlenwert einsetzen: Die Anwendung kann durch zu grosszügige SPL-Grenzen verdrängt werden, während zu enge Grenzen Schutzprozesse beenden. Änderungen erfolgen im Wartungsfenster nach der lokalen README; Sophos verlangt dafür, sophos-spl.service vor dem Bearbeiten zu stoppen und danach wieder zu starten. Anschliessend werden Dienststatus, watchdog.log, Journal, Central-Health und die geschäftskritische Anwendung erneut geprüft.

Klone teilen eine Identität oder das Template taucht wieder auf

Die Bereitstellung stoppen. Prüfen, ob der Master nach registerCentral --deregister wirklich heruntergefahren und im ausgeschalteten Zustand gespeichert wurde. Wurde er erneut gestartet, vor dem Speichern nochmals deregistrieren. Fehlerhafte Klone nicht zum nächsten Template machen; aus dem korrekt vorbereiteten Gold Image neu erzeugen.

Häufige Fragen