synOCR synOCR vollständig deinstallieren

[mle]

Hallo, bin Nutzer einer DS218+ auf DSM 7.2 und neu hier. Teste gerade synOCR.
Ich habe ein paar Verständnisfragen:
Kann man synOCR wieder restlos von seiner Syno entfernen und wie?
Nach einer testweisen Deinstallation habe ich festgestellt, dass z.B. der Benutzer synOCR immer noch angelegt ist und man manuell über die Systemsteuerung keinen Benutzer mehr mit dem Namen synOCR anlegen kann.

Was verbleibt nach Deinstallation sonst noch alles im System?

Stellt der verbleibende Benutzer, der wie ich es verstehe ja admin-Rechte hat, ein Sicherheitsrisiko dar?

Lässt sich auch das Paket inotfiy-Tools wieder restlos aus dem System entfernen?

Vorab schon mal Danke für eure Antworten.

 

[plang.pl]

Willkommen hier im Forum!
Ja, das geht. Einfach das Paket im Paket-Zentrum deinstallieren. Ggfs. dann noch das Image OCRmyPDF im Container Manager löschen. Das mit dem Benutzer hatten wir schonmal bei anderen Paketen, dass die nicht entfernt werden. Ich wüsste nicht, wie man das manuell löschen kann.
Vielleicht kann hier @geimist oder / und @Tommes mehr dazu sagen.

 

[Tommes]

Hi!

Vielleicht kann hier […] @Tommes mehr dazu sagen.

Ich verfolge einen anderen Ansatz als @geimist, was das Erweitern und/oder Zurücknehmen von App-Berechtigungen - und damit verbunden - das Hinzufügen und/oder Entfernen von Gruppenzugehörigkeiten angeht. Mittlerweile kann man das in meinen installierten Apps bequem über die GUI bzw. über dem Aufgabenplaner lösen. Soweit ich weiß, läuft das bei @geimist bestenfalls über die Konsole, aber dazu kann er selbst ja evtl. etwas sagen. Ich finde nämlich grad nicht mehr meine Notzien, wo ich den Weg beschrieben hatte, wie wir das früher gemacht haben.

Was ich grad aber gefunden habe, ist eine Art Deinstallationsscript, welches ich mir mal gebastelt hatte um meine als auch die Apps von @geimist sauber deinstallieren zu können. Wobei sauber eigentlich schon übertrieben ist. Denn eigentlich bleiben nach einer Deinstallation über das Paketzentrum, wenn überhaupt, nur unwichtige Dinge zurück, die für eine spätere Neuinstallation evtl. interessant sein könnten. Einzig die Tatsache, das synOCR in der Gruppe der Administratoren verbleibt ist etwas unglücklich, wenngleich ich das aber nicht als Sicherheitsrisiko ansehe.

Lange Rede kurzer Sinn, ich werde schauen, wo ich meine Notizen vergraben habe und teste nochmal das Deinstallationsscript. Sollte sich @geimist bis dahin noch nicht gemeldet haben, poste ich meine Erkenntnisse, sobald diese vorliegen.

Tommes

 

[Tommes]

Ich habe jetzt mal ein paar Tests durchgeführt, um einen Vergleich zu erhalten, welche Gruppenzugehörigkeiten, Ordner und Dateien bei einem installierten synOCR vorhanden sind und welche nach der Deinstallation von synOCR über das Paketzentum noch übrig bleiben. Anhand dieser Informationen habe ich mir dann ein Script zusammen gefummelt, das es mir ermöglicht, synOCR so gut wie vollständig aus dem DSM zu verbannen. Am Ende bleiben nur eine Handvoll Dateien übrig, die der DSM wohl mit irgendwelchen Services verbindet. An diese Dateien habe ich mich erstmal nicht dran getraut, sollten meines Erachtens aber zu vernachlässigen sein. Also dann, ein kurzer Ausflug....

Ich habe zum Testen synOCR auf meinem VirtualDSM 7.2 installiert. Dann habe ich auf der Konsole mit...

grep synOCR /etc/group

...geschaut, in welche Benutzergruppen sich synOCR eingeschrieben hat.

Danach habe ich nach allen Ordnern gesucht, die den Namen synOCR in sich tragen...

find / -type d -name "*synOCR*"

... und gleiches mit der Suche nach Dateien wiederholt...

find / -type f -name "*synOCR*"

Spoiler: Ergebnisse mit installierter synOCR App

root@Virtualserver:# grep synOCR /etc/group
administrators:x:101:admin,synOCR
docker:x:65536:synOCR
synOCR:x:199758:
synopkgs:x:999ython2,QuickConnect,SecureSignIn,FileStation,OAuthService,SynoFinder,synOCR,HyperBackup,StorageManager
system:x:1:system,synOCR

root@Virtualserver:~# find / -type d -name "*synOCR*"
/var/packages/synOCR
/sys/fs/cgroup/blkio/synOCR.slice
/sys/fs/cgroup/cpu/synOCR.slice
/sys/fs/cgroup/cpuacct/synOCR.slice
/sys/fs/cgroup/devices/synOCR.slice
/sys/fs/cgroup/memory/synOCR.slice
/sys/fs/cgroup/synomonitor/synOCR.slice
/sys/fs/cgroup/systemd/synOCR.slice
/volume1/@appstore/synOCR
/volume1/@appdata/synOCR
/volume1/@apptemp/synOCR
/volume1/@apphome/synOCR
/volume1/@appshare/synOCR
/volume1/@appconf/synOCR
/volume1/@tmp/synopkg/lfs/image/INST/synOCR

root@Virtualserver:~# find / -type f -name "*synOCR*"
/var/log/packages/synOCR.log
/var/log/systemd/pkgctl-synOCR.service.log
/usr/local/lib/systemd/system/pkgctl-synOCR.service
/usr/local/lib/systemd/system/synOCR.slice
/usr/syno/etc/synosystemd/enable-status-changed/pkgctl-synOCR.service
/run/ActiveInsight/collector_load_offload/.synOCR_install_for_mib_exporter
/run/ActiveInsight/collector_load_offload/.synOCR_uninstall_for_mib_exporter
/run/synopkg/lock/synOCR.lock
/run/synopkg/pkglist/security_version/synOCR.1.4.99.1.enu
/tmp/synOCR.status
/tmp/synOCR.start
/volume1/@appstore/synOCR/ui/images/._synOCR_48.png
/volume1/@appstore/synOCR/ui/images/synOCR_48.png
/volume1/@appstore/synOCR/ui/images/._synOCR_64.png
/volume1/@appstore/synOCR/ui/images/synOCR_64.png
/volume1/@appstore/synOCR/ui/images/._synOCR_256.png
/volume1/@appstore/synOCR/ui/images/synOCR_256.png
/volume1/@appstore/synOCR/ui/images/._synOCR_120.png
/volume1/@appstore/synOCR/ui/images/synOCR_120.png
/volume1/@appstore/synOCR/ui/images/._synOCR_72.png
/volume1/@appstore/synOCR/ui/images/synOCR_72.png
/volume1/@appstore/synOCR/ui/images/._synOCR_16.png
/volume1/@appstore/synOCR/ui/images/synOCR_16.png
/volume1/@appstore/synOCR/ui/images/._synOCR_32.png
/volume1/@appstore/synOCR/ui/images/synOCR_32.png
/volume1/@appstore/synOCR/ui/images/._synOCR_24.png
/volume1/@appstore/synOCR/ui/images/synOCR_24.png
/volume1/@appstore/synOCR/ui/images/._synOCR_128.png
/volume1/@appstore/synOCR/ui/images/synOCR_128.png
/volume1/@appstore/synOCR/ui/images/._synOCR_512.png
/volume1/@appstore/synOCR/ui/images/synOCR_512.png
/volume1/@appstore/synOCR/ui/images/._synOCR_90.png
/volume1/@appstore/synOCR/ui/images/synOCR_90.png
/volume1/@appstore/synOCR/ui/etc/synOCR.sqlite
/volume1/@appstore/synOCR/ui/._synOCR.js
/volume1/@appstore/synOCR/ui/synOCR.js
/volume1/@appstore/synOCR/ui/._synOCR-start.sh
/volume1/@appstore/synOCR/ui/synOCR-start.sh
/volume1/@appstore/synOCR/ui/._synOCR.sh
/volume1/@appstore/synOCR/ui/synOCR.sh
/volume1/@appstore/synOCR/bin/._synOCR-cli
/volume1/@appstore/synOCR/bin/synOCR-cli

Anschließend habe ich synOCR über das Paketzentrum deinstalliert und wieder meine o.a. Suche durchgeführt.

Spoiler: Ergebnisse nach der Deinstallation der synOCR App

root@Virtualserver:# grep synOCR /etc/group
administrators:x:101:admin,synOCR
docker:x:65536:synOCR
synOCR:x:199758:
synopkgs:x:999ython2,QuickConnect,SecureSignIn,FileStation,OAuthService,SynoFinder,synOCR,HyperBackup,StorageManager
system:x:1:system,synOCR

root@Virtualserver:~# find / -type d -name "*synOCR*"
/sys/fs/cgroup/blkio/synOCR.slice
/sys/fs/cgroup/cpu/synOCR.slice
/sys/fs/cgroup/cpuacct/synOCR.slice
/sys/fs/cgroup/devices/synOCR.slice
/sys/fs/cgroup/memory/synOCR.slice
/sys/fs/cgroup/synomonitor/synOCR.slice
/sys/fs/cgroup/systemd/synOCR.slice
/volume1/@appdata/synOCR
/volume1/@apphome/synOCR
/volume1/@appshare/synOCR
/volume1/@appconf/synOCR

root@Virtualserver:~# find / -type f -name "*synOCR*"
/var/log/packages/synOCR.log
/var/log/systemd/pkgctl-synOCR.service.log
/run/ActiveInsight/collector_load_offload/.synOCR_install_for_mib_exporter
/run/ActiveInsight/collector_load_offload/.synOCR_uninstall_for_mib_exporter
/run/synopkg/pkglist/security_version/synOCR.1.4.99.1.enu
/tmp/synOCR.stop
/tmp/synOCR.status
/tmp/synOCR.start

Zu guter Letzt habe ich mein selbst zusammen getummeltes Script ausgeführt um dann abermals die o.a. Suche durchzuführen. Das Ergebnis kann sich sehen lassen...

Spoiler: Ergebnisse nach der Ausführung meines Deinstallations-Scriptes

root@Virtualserver:~# grep synOCR /etc/group

root@Virtualserver:~# find / -type d -name "*synOCR*"
/sys/fs/cgroup/blkio/synOCR.slice
/sys/fs/cgroup/cpu/synOCR.slice
/sys/fs/cgroup/cpuacct/synOCR.slice
/sys/fs/cgroup/devices/synOCR.slice
/sys/fs/cgroup/memory/synOCR.slice
/sys/fs/cgroup/synomonitor/synOCR.slice
/sys/fs/cgroup/systemd/synOCR.slice

root@Virtualserver:~# find / -type f -name "*synOCR*"
/run/ActiveInsight/collector_load_offload/.synOCR_install_for_mib_exporter
/run/ActiveInsight/collector_load_offload/.synOCR_uninstall_for_mib_exporter
/run/synopkg/pkglist/security_version/synOCR.1.4.99.1.enu

Wie man sieht, sind noch ein paar Reste übrig geblieben, an die ich mich aber nicht dran traue. Ebenfalls ist mir bei meinen Tests aufgefallen, das auch meine Apps immer noch Spuren im System hinterlassen. Vielleicht ist es an der Zeit, generell ein Deinstallationsscript zu schreiben, damit meine und die Apps von @geimist sauber vom System entfernt werden.

Ich prüfe das Script noch mal eingehend und werde es dann wohl hier veröffentlichen, wenn ihr das möchtet. Vielleicht gehe ich aber auch einen anderen Weg und besprech mich diesbezüglich nochmal mit @geimist der ja bestimmt hier mitliest bzw. drüber stolpert.

Tommes

 

[geimist]

Idealerweise sollte man das paketeigene Uninstallskript entsprechend erweitern. Hier müsste man allerdings mal prüfen, ob der entsprechende Prozess die nötigen Rechte besitzt, damit es bei der Deinstallation automatisch funktioniert.

Ich verfolge einen anderen Ansatz als @geimist, was das Erweitern und/oder Zurücknehmen von App-Berechtigungen

Ja, ich hatte mich an deine Variante damals nicht herangetraut, weil ich nicht riskieren wollte, die Administratorengruppen zu zerstören. Du hattest es damals nur für eine unkritische Gruppe verwendet. Da es aber inzwischen (bei LogAnalysis) auch mit der Admingruppe scheinbar problemlos bei dir funktioniert, habe ich schon mit dem Gedanken gespielt, das umzustellen. Leider habe ich derzeit gar keine Ressourcen übrig …

Stellt der verbleibende Benutzer, der wie ich es verstehe ja admin-Rechte hat, ein Sicherheitsrisiko dar?

Dazu muss man wissen, dass diese Paketuser nur interne User sind, welche konzeptbedingt vom DSM aus auch keine Loginberechtigung haben.

 

[Tommes]

Moin!

Wir schweifen zwar ein wenig ab, trotzdem gehört es ja noch zum Thema.

Idealerweise sollte man das paketeigene Uninstallskript entsprechend erweitern.

Ich meine mich zu erinnern, das ich das alles schon durchexerziert habe. Hätten wir in den - ich nenn sie mal "Lifecycle scripts of a package" - genügend Rechte, könnte man bereits während der Installation unsere Apps in die richtigen Gruppen schubsen und müssten nicht den Umweg über den Aufgabenplaner oder das Terminal gehen. Ich bekomme über diese "Lifecycle scripts of a package" z.B. auch nicht die UDEV-Regel für AutoPilot dort platziert, wo ich sie haben möchte und bekomm diese Regel auch bei einer Deinstallation des Paketes nicht mehr entfernt.

Ja, ich hatte mich an deine Variante damals nicht herangetraut, weil ich nicht riskieren wollte, die Administratorengruppen zu zerstören.

No risk, no fun

Aber ja, ich kenne deine Bedenken und würde dir diese auch gerne nehmen. Aber viele Wege führen bekanntlich nach Rom und solange wir beide keine Probleme mit unseren Lösungen haben, besteht auch kein zwingender Handlungsbedarf. Du katapultierst deinen Benutzer halt mit sed in die Gruppe, die du haben willst. Ich lese dagegen alle Benutzer einer Gruppe über eine for Schleife aus und füge meinen Benutzer über den Synology eigenen Befehl synogroup der Gruppe hinzu. Umgekehrt kann ich auf die gleiche Weise einen Benutzer wieder entfernen - aber halt nur mit root Rechten. Wie ich immer sage...Der Weg ist das Ziel!

Da es aber inzwischen (bei LogAnalysis)

LogAnalysis benötigt neben der Gruppe system und synopkgs eigentlich nur noch die Gruppe log um zu funktionieren. Wohingegen BasicBackup zum funktionieren die Administratorengruppe benötigt, genau wie AutoPilot auch. Aber das nur am Rande.

Dazu muss man wissen, dass diese Paketuser nur interne User sind, welche konzeptbedingt vom DSM aus auch keine Loginberechtigung haben.

Das ist in der Tat richtig. Nichtsdestotrotz finde ich es schade, das wir diesen inoffiziellen Weg gehen müssen, da uns Synology an dieser Stelle einen dicken fetten Riegel vorgeschoben hat, indem man uns inoffiziellen Developer die Möglichkeit genommen hat, erweiterte Rechte für unsere Pakete zu erhalten. Offizielle Developer können hingegen auch mit root Rechten hantieren. Egal...

Leider habe ich derzeit gar keine Ressourcen übrig …

Willkommen in meiner Welt. Ich weiß langsam auch nicht mehr, wie ich immer alles unter einen Hut bekommen soll. Aktuell überarbeite ich auf Wunsch (und weil es absolut Sinn macht) die Funktionsweise von AutoPilot um die Sicherheit zu erhöhen. Gestern habe ich dann auf meinem Zettel mit Dingen, die ich noch erledigen wollte (und dieser Zettel ist echt lang geworden und wird irgendwie nie kürzer) geschrieben, das ich ein Uninstall-Script für unsere Pakete schreiben möchte. Ich habe aber ehrlich gesagt noch keine Ahnung, wann ich das machen soll. Du bist also nicht der Einzige mit Ressourcenproblemen

So, Schluss jetzt. Ich brauch 'n Kaffee

Tommes

 

[mle]

Hallo,
plang.pl, Tommes und geimist, vielen Dank für eure Erläuterungen.
Eine definierte, „offizielle“ Deinstallations-Methode wäre, denke ich, sinnvoll und beruhigend - vor allem für Nutzer die nicht wie Ihr Profis mit eurem know how sind.
Vielleicht könnte man das auch entsprechend ins wiki aufnehmen.

 

[geimist]

Deinstalliert wird ja grundsätzlich über das Paketsystem des DSM - allerdings nicht restlos.
Wenn User "mit weniger know how" ein Skript manuell mit Root-Rechten ausführen, birgt das auch gewisse Gefahren, deren er sich bewusst sein sollte. Das nur am Rande.

 

[Tommes]

Nichtsdestotrotz werde ich in Abstimmung mit @geimist versuchen, eine Routine in Form eines Shell-Scriptes zu konstruieren, die nach der eigentlichen Paket-Deinstallation sowohl meine als auch seine Pakete so gut wie vollständig aus dem DSM über die Konsole oder über den DSM-Aufgabenplaner entfernen kann. Aber wie gesagt... ich weiß noch nicht wann genau ich dazu komme. Aktuell bin ich dabei, ein größeres Update für AutoPilot auszurollen und im Anschluss daran muss ich noch ein Problem in Basic Backup fixen. Das hat erst mal Vorrang. Aber ich hab's auf dem Zettel...