AvrLogger : Thermallogger und Visualisierung Tool

[darkmerlin1512]

@Kurt-oe1kyw das hast du gemacht?
als root über ssh die Rechte dafür setzen: "/var/packages/AvrLogger/scripts/start-stop-status root"

 

[BigRonin]

Schaue ich mir an

 

[BigRonin]

So ein Mist !!!!!

Ich habe einen riesen Bock geschossen ? ... es tut mir soooo leid ?.

Ich habe in dem Script das AvrLogger "rootet" einen Fehler eingebaut ? :

Anstelle des AvrLogger Pfades : /volume1/@appconf/AvrLogger
habe ich /volume1/@appconf eingesetzt.

Jetzt haben alle Ordner und Dateien dort, nach der Ausführung des rooten, als Gruppe / Eigentümer "AvrLogger:AvrLogger"

??? Das kann ich ja niiiiiiie wieder gutmachen.

Ich hab die DSM7 Version vom SPK-Server gelöscht ...

Bitte bitte bitte ... für das Rooten nicht aus !!!!

 

[synfor]

Die Warnung kommt leider zu spät. AvrLogger funktioniert hier auf der DS218j bisher problemlos. Allerdings hab ich da noch nicht den richtigen Durchblick.

 

[Benares]

@BigRonin
Meinst du etwa, dass alle Ordner/Dateien unter /volume1/@appconf hinterher AvrLogger gehören? Das wäre allerdings krass
Wenn da nur direkt einige Logs direkt lägen, ginge es ja noch.

 

[Kurt-oe1kyw]

Ich habe bei mir auf der Test-DS gerade nachgesehen, da sind bei mir noch alle Rechte unverändert, da wurde durch AvrLogger nichts verändert.
Vermutlich weil das Paket bei mir nach der Installation nicht gestartet werden konnte.
Also soweit alles gut hier.

 

[BigRonin]

Meinst du etwa, dass alle Ordner/Dateien unter /volume1/@appconf hinterher AvrLogger gehören?

? ... leider ja ?.

Ich habe bei mir auf der Test-DS gerade nachgesehen, da sind bei mir noch alle Rechte unverändert

Die Rechte werden erst mit dem "rooten" von AvrLogger über das StartScript (muss händisch per Terminal gemacht werden) geändert.

Mir ist die Sache höchst unangenehm ... sowas darf nicht passieren ?.

Ich kann mich nur noch mal entschuldigen.

Ich habe inzwischen die Besitzer:Gruppe in "/volume1/@appdata" verglichen mit den in "/volume1/@appconf" und händisch (rekursiv) übertragen.
Das ist eine Möglichkeit den dummen Fehler wieder zu korrigieren und ich hoffe das damit alles wieder in Ordnung ist.

Ich weiss noch nicht ob und wann ich die DSM7-Version wieder online stellen werde ... es tut mir leid ?.

 

[Tommes]

Hilft es vielleicht, wenn man über das Paketzentrum die jeweilige App einmal stoppt und anschließend startet, damit sich die Besitzer:Gruppen Einstellungen wieder anpassen.

 

[geimist]

Mir ist die Sache höchst unangenehm ... sowas darf nicht passieren ?.

Mir tut es auch leid für dich. So etwas will niemand!
Und trotz aller Vorsicht können nun einmal Fehler passieren.

Mir zeigt das aber auch: Die Sicherheit, die Synology durch die Anpassung / Einschränkung für 3rd-Party-SPKs herbeiführen wollte, kann z.T. genau das Gegenteil bewirken. Denn entweder müssen User komplett auf Pakete verzichten (da sie ohne Root einfach nicht funktionieren), oder die Entwickler werden zu zusätzlichen (waghalsigeren) Klimmzügen gedrängt, wobei das Gefahrenpotential beim Umschiffen der Hürden weitaus höher ist.

Eine zusätzliche Option im Paketzentrum (ähnlich der signierten Quellen im DSM6) zum Zulassen der Rootberechtigungen für 3rd-Party-SPKs wäre hier aus meiner Sicht der bessere Weg.

Hilft es vielleicht, wenn man über das Paketzentrum die jeweilige App einmal stoppt und anschließend wieder startet, damit sich die Rechte wieder anpassen.

Bzw. die gleiche Version mal drüberinstallieren.

 

[BigRonin]

Hilft es vielleicht, wenn man über das Paketzentrum die jeweilige App einmal stoppt und anschließend startet

Das scheint an dem Besitzer:Gruppe nichts zu ändern ... gerade ausprobiert.

Bzw. die gleiche Version mal drüberinstallieren.

Ich habe mal "/var/packages/SynologyApplicationService/enabled" umbenannt in "/var/packages/SynologyApplicationService/startFailed"
Danach wurde ich zu Reparatur des Paketes im Paket Manger aufgefordert ... leider hat es an Besitzer:Gruppe nichts geändert.

Ein "drüberinstallieren" hab ich noch nicht versucht.

@geimist : Ja ... da stimme ich dir zu. Viel schlimmer finde ich noch, das Synology „nach“ den Betatests Änderungen an der Ordnerstruktur macht und wer weiss was Sie noch für Änderungen nachträglich vornehmen.

 

[darkmerlin1512]

hi,

komt vor, kann vorkommen, wird immer vorkommen, wem sowas noch nie passiert ist, darf gerne meckern.

So, nach einen Update oder neuinstall, werden die rechte wohl wieder gesetzt.

 

[AndiHeitzer]

@BigRonin
Würde es Dir denn helfen, wenn wir hier die Verzeichnisse unter /volume1/@appdata abliefern würden?
Natürlich nur bei denen, die quasie den AvrLogger (noch) nicht eingesetzt haben.

 

[BigRonin]

Nicht /volume1/@appdata aber /volume1/@appconf ?? (in /volume1/@appdata habe ich definitive nichts gemacht ... nur in /volume1/@appconf)

 

[AndiHeitzer]

So, nach einen Update oder neuinstall, werden die rechte wohl wieder gesetzt.

Ich packe mal Screenschots rein. Alles von DSM7.
Der AVRLogger ist bei mir nicht (mehr) drauf. Hat drei Gründe, der erste war eine stabile Version für DSM7, der zweite war, dass ich da nie reingeschaut habe, es lief halt, und der dritte Grund war die lange Abwesenheit von BigRonin.

Nun die Bildchen:

Die eingerahmten Verzeichnisse sind den vier Paketen geschuldet, die ich gerne nutze.

 

[Benares]

Hier mal von mir:

root@DS415:/volume1/@appconf# ls -als
total 176
4 drwxr-xr-x 44 root                       root                       4096 Aug 23 15:12  .
4 drwxr-xr-x 48 root                       root                       4096 Sep 11 10:44  ..
4 drwxr-xr-x  2 root                       root                       4096 May 27  2017  Apache2.4
4 drwxr-xr-x  4 AudioStation               AudioStation               4096 Jul 18 12:09  AudioStation
4 drwxr-xr-x  2 root                       CloudSync                  4096 Jul  8  2020  CloudSync
4 drwxr-xr-x  2 root                       root                       4096 Feb 27  2021  CodecPack
4 drwxr-xr-x  3 root                       root                       4096 Mar 24  2016  DirectoryServer
4 drwxr-xr-x  3 DNSServer                  DNSServer                  4096 Apr 15  2020  DNSServer
4 drwxr-xr-x  3 root                       root                       4096 Sep 11 10:44  Docker
4 drwxr-xr-x  5 DownloadStation            DownloadStation            4096 Jul 12  2019  DownloadStation
4 drwxr-xr-x  2 root                       root                       4096 Jul 23  2019  Git
4 drwxr-xr-x  2 root                       HyperBackup                4096 Mar 24  2016  HyperBackup
4 drwxr-xr-x  2 root                       root                       4096 Mar 24  2016  HyperBackupVault
4 drwxr-xr-x  2 iTunesServer               iTunesServer               4096 May 14  2015  iTunesServer
4 drwxr-xr-x  2 lcd4linux                  lcd4linux                  4096 May 17  2015  lcd4linux
4 drwxr-xr-x  2 root                       root                       4096 Sep  7 14:31  MariaDB10
4 drwxr-xr-x  2 MediaServer                MediaServer                4096 Sep 11 10:44  MediaServer
4 drwxr-xr-x  2 root                       root                       4096 Mar 24  2020  Node.js_v12
4 drwxr-xr-x  2 root                       root                       4096 Feb 16  2019  Node.js_v4
4 drwxr-xr-x  2 root                       root                       4096 Jul 23  2019  Node.js_v8
4 drwxr-xr-x  3 root                       root                       4096 Dec 12  2018  Perl
4 drwxr-xr-x  3 PhotoStation               PhotoStation               4096 Jun 22 10:00  PhotoStation
4 drwxr-xr-x  2 root                       root                       4096 Mar 24  2016  PHP5.6
4 drwxr-xr-x  2 root                       root                       4096 Mar 24  2017  PHP7.0
4 drwxr-xr-x  2 root                       root                       4096 Jun 18  2020  PHP7.2
4 drwxr-xr-x  2 root                       root                       4096 Feb 27  2021  PHP7.3
4 drwxr-xr-x  3 phpMyAdmin                 phpMyAdmin                 4096 Sep  7 14:30  phpMyAdmin
4 drwxr-xr-x  2 PlexMediaServer            PlexMediaServer            4096 Jun 30 12:41  PlexMediaServer
4 drwxr-xr-x  2 root                       root                       4096 May 14  2015 'Plex Media Server'
4 drwxr-xr-x  2 root                       root                       4096 Jun 30 12:25  ProxyServer
4 drwxr-xr-x  2 root                       root                       4096 Jan  5  2021  r8152
4 drwxr-xr-x  2 root                       root                       4096 May 13  2015  RadiusServer
4 drwxr-xr-x  2 StorageAnalyzer            system                     4096 Mar 24  2016  StorageAnalyzer
4 drwxr-xr-x  3 SurveillanceStation        SurveillanceStation        4096 Jul  8 13:24  SurveillanceStation
4 drwxr-xr-x  3 SynologyApplicationService SynologyApplicationService 4096 Sep 11 10:44  SynologyApplicationService
4 drwxr-xr-x  5 root                       SynologyDrive              4096 Sep 11 10:45  SynologyDrive
4 drwxr-xr-x  2 SynologyMoments            SynologyMoments            4096 Jun 30 12:29  SynologyMoments
4 drwxr-xr-x  2 SynologyPhotos             SynologyPhotos             4096 Jul 17 19:27  SynologyPhotos
4 drwxr-xr-x  2 root                       root                       4096 Mar 24  2016  TextEditor
4 drwxr-xr-x 11 VideoStation               VideoStation               4096 Jun 30 12:27  VideoStation
4 drwxr-xr-x  2 root                       root                       4096 May 17  2015  virtualbox
4 drwxr-xr-x  6 root                       root                       4096 Jun 30 12:27  VPNCenter
4 drwxr-xr-x  2 root                       root                       4096 Mar 24  2016  WebDAVServer
4 drwxr-xr-x  8 root                       root                       4096 Sep 11 10:44  WebStation

Edit: /volume1/@appdata ist auch eine gute Vorlage, da sitzen die Owner/Groups genauso.

 

[AndiHeitzer]

Nicht /volume1/@appdata aber /volume1/@appconf ?? (in /volume1/@appdata habe ich definitive nichts gemacht

Grmpff ... ?
Aber ich brauch keine neuen Screenshots machen, die Struktur ist identisch aufgebaut
Und wenn Du dort im 'appdata' nix gemacht hast, dann wäre meine Schnappsidee, im 'appdata' Berechtigung auslesen und im 'appconf' entsprechend zu setzen ...

 

[Tommes]

Sollte es so sein, das…

…die Struktur […] identisch aufgebaut…

…ist, dann kann man sich selber ja die nötigen Infos einholen. Theoretisch sollte das ja so sein und bei mir scheint das auch so zu sein. Macht auch Sinn

 

[BigRonin]

... wäre das eine Möglichkeit, einen Abgleich der Besitzer/Gruppe, per Script zu machen?

Ich könnte / würde so Script zur Verfügung stellen ?

 

[Tommes]

Ich hab AvrLogger bei mir nicht installiert, denke aber, das es eine ziemlich gute Möglichkeit wäre um den Fehler wieder glatt zu bügeln. Was soll schon passieren? Die Struktur hat es unter @appconf eh zerrissen. Es kann also nur besser werden. Ich würde es an deiner Stelle auf jeden Fall mal testen.

 

[BigRonin]

Danke @Tommes , das werde ich mach ??