DSM 7.0 Public Beta - Erfahrungen, Probleme, Bugs

[Tommes]

Wer mag, darf sich gerne mal LogAnalysis für die DSM 7 Public Beta anschauen und mir vielleicht sogar ein Feedback geben, ob es Sinn macht die App unter DSM7 Final weiter zu supporten oder in Anbetracht der Umstände (weitere Infos im beigefügten Link) es doch besser sein zu lassen.

Tommes

 

[Tommes]

Kurzes Update: Ich konnte es selbst kaum glauben, aber es läuft! *klick*

 

[Andy+]

Ich habe es mal getestet, allerdings nur Installation, keine weiteren Anpassungen. Es läuft, kann aber nicht geöffnet werden.

 

[Tommes]

@Andy+
Für den Moment... versuch mal bitte, die erste Version von LogAnalysis aus dem anderen Thread zu installieren. Sollte es dann funktionieren, wüsste ich wohl schon, woran es liegt.

 

[Andy+]

Die "erste" Version, Dein gestriger Post von 13:07 Uhr funktioniert.

 

[Tommes]

Das dachte ich mir. Und trotz, das du nun die erste Version installiert hast, hast du nun vollen Lesezugriff auf den Ordner var/log, richtig?

Zu den Hintergründen. Damit ein SPK unter der DSM7 Public Beta funktioniert, wird während der Installation ein neuer Benutzer (in diesem Falle heißt der Benutzer LogAnalysis) angelegt und dieser in einer ganz bestimmten System Benutzergruppe eingetragen um das SPK anschließend verwenden zu können. Dieses erfolgte in der ersten Version meines SPKs.

Damit man jedoch vollen Lese- und sogar Schreibrechte für den Ordner /var/log erhält, muss das SPK eigentlich noch Mitglied in einer weiteren Benutzergruppe sein. Dieses erfolgte dann - separat -in der zweiten Version meines SPKs.

Das dumme ist nur, das man während der Installation - Stand heute - das SPK nur in eine Benutzergruppe stecken kann, nicht jedoch in mehrere gleichzeitig. Das gute ist, das der Benutzer auch dann noch in der Benutzergruppe verbleibt, selbst wenn das SPK wieder deinstalliert wird.

Bei dir ist nun folgendes passiert. Du hast Version 2 installiert und bist mit dem Benutzer in die Benutzergruppe aufgenommen worden, die dir Schreib- und Leserechte für /var/log gibt, nicht jedoch in die System Benutzergruppe, um das SPK benutzen zu dürfen. Nachdem du die Version 1 installiert hast, konntest du das SPK dann starten, da der Benutzer LogAnalysis nun Mitglied in beiden Benutzergruppen ist.

@Tosoboso und ich versuchen aktuell diese Nuss zu knacken, so das man während der Installation eines SPKs gleich in mehreren Benutzergruppen Mitglied werden kann. Es bleibt also weiter spannend… und das sind die Dinge, wo Synology uns unnötig das Leben mit schwer macht.

Tommes

 

[Andy+]

Ohne nun das Paket genau zu kennen würde ich sagen, es funzt. Ich kann in die Unterverzeichnisse, Suchen starten usw. Die Frage wäre, wie sollte man gucken, wie es nicht geht (?), oder was aus Deiner Sicht kritisch erscheint. Wenn das Erscheinungsbild zur v0.5 korrespondiert, würde ich jedenfalls sagen, es funzt. .... ?

 

[Tommes]

Je weniger rote Datei-Icons du vor einer Datei findest desto bessser. Alle lesbaren (und teilweise sogar schreibbaren) Dateien ist ein dunkelgraues Symbol vorangestellt, bei gelben Symbolen handelt es sich um gepackte Dateien und bei roten um nicht les- und durchsuchbare Dateien. Je weniger rote Dateien du also hast, um so größer ist die Wahrscheinlichkeit das alles funktioniert wie es soll.



Hättest du zuerste die Version 1 - und nur die Version 1 - installiert, wären ca. 75 - 80 % der Dateien mit einem roten Symbol versehen gewesen. Wenn du es genau wissen willst, müsstest du über die Konsole den Benutzer LogAnalysis nochmal aus der Gruppe log entfernen, dann könntest du den Unterschied sehen. Das löschen aus der Gruppe ist aber nicht ganz ohne und man sollte wissen, was man da tut. Bei Bedarf schick ich dir aber genre eine PN, wie das geht. PN deshalb, damit nicht jeder auf die Idee kommt, in den Benutzergruppen rumzuspielen.

Solange LogAnalysis in beiden Benutzergruppen vertreten ist, funktionert es augenscheinlich mit dem gleichen Funktionsumfang wie unter Version 0.5 für DSM 6.x

Tommes

 

[Andy+]

Rot ist nichts, Gelb gibt es 17, der Rest ist Grau.

 

[Tosoboso]

Damit man jedoch vollen Lese- und sogar Schreibrechte für den Ordner /var/log erhält, muss das SPK eigentlich noch Mitglied in einer weiteren Benutzergruppe sein. Dieses erfolgte dann - separat -in der zweiten Version meines SPKs.
Das dumme ist nur, das man während der Installation - Stand heute - das SPK nur in eine Benutzergruppe stecken kann, nicht jedoch in mehrere gleichzeitig. Das gute ist, das der Benutzer auch dann noch in der Benutzergruppe verbleibt, selbst wenn das SPK wieder deinstalliert wird.
@Tosoboso und ich versuchen aktuell diese Nuss zu knacken, so das man während der Installation eines SPKs gleich in mehreren Benutzergruppen Mitglied werden kann. Es bleibt also weiter spannend… und das sind die Dinge, wo Synology uns unnötig das Leben mit schwer macht.
Tommes

Also, da zur Zeit nur eine Gruppe möglich ist, ist der bessere Weg, die Gruppe Log zu verwenden und auf System zu verzichten.
Das geht so: die Synology Api Dateien (login.cgi, authenticate.cgi, synowebapi) mit dem SPK im UI/modules Verzeichnis aus zurollen, dann gehören Diese dem Paket User und können ausgeführt werden (leider muss man bei Upgrades dies neu ausrollen). Die Befehlsfolge sieht dann so aus (ganz ohne php):

..
APP_HOME=$(echo /volume*/@appstore/LogAnalysis/ui)
SYNO_LOGIN=$($APP_HOME/modules/login.cgi)
SYNO_TOKEN=$(echo "$SYNO_LOGIN" | grep "SynoToken" | cut -d ":" -f2 | cut -d '"' -f2)
QUERY_STRING="SynoToken=${SYNO_TOKEN}"
SYNO_USER=$($APP_HOME/modules/authenticate.cgi)
if ! id -G "$SYNO_USER" | grep -q 101 ; then
    echo "not part of admin group"
    exit
fi

Königsklasse, wenn du die App-Berechtigung Testen willst jenseits des Lokalen Admins:

..
MYPKG="LogAnalysis"
RAW_DATA=$($APP_HOME/modules/synowebapi --exec api=SYNO.Core.Desktop.Initdata method=get version=1 runner="$SYNO_USER" | jq '.data.AppPrivilege')
APP_DATA=$(echo "$RAW_DATA" | grep "SYNO.SDS.App.$MYPKG" | cut -d ":" -f2 | cut -d '"' -f2)
if ! echo "$APP_DATA" | grep -q "true"  ; then
    echo "not application privileges for user $SYNO_USER"
    exit
fi

 

[Tommes]

Das geht so: die Synology Api Dateien (login.cgi, authenticate.cgi, synowebapi) mit dem SPK im UI/modules Verzeichnis aus zurollen, dann gehören Diese dem Paket User und können ausgeführt werden

Dumm nur, das nur die authenticate.cgi über die Rechte 755 (rwxr-xr-x system) verfügt und somit während der SPK Insatallation umkopiert werden kann und entsprechende chown Rechte gesetzt werden können. Der login.cgi 550 (r-xr-x--- system) sowie der synowebapi 700 (rwx------ root) fehlt aber ein Lese- und/oder Ausführungsrecht, damit man die Dateien überhaupt bewegt bekommt.

Leider habe ich nicht rausbekommen, wie ich z.B. in der postinst root Rechte erlangen kann, um die o.a. Operation durchzuführen. Wenn ich versuche, mir in der privilege root Rechte für die postinst zu ergaunern...

"ctrl-script":[{
    "action": "postinst",
    "run-as": "root"
    }]

... scheitert die Installation mit dem Hinweis, das ich versuche, das Paket als root installieren zu wollen. Ein umbennenen von root in system funktioniert hier genauso wenig. Von daher komm ich da grade irgendwie nicht weiter bzw. drehe mich im Kreis, da mir so oder so immer irgendwo die nötigen Rechte fehlen.

Ich habe jedoch in deinem jitsimeet SPK für DSM7 gesehen das du in der common die o.a. Dateien kopierst. Da auf meiner DSM7-VM noch kein Docker installiert ist, habe ich dein SPK noch nicht installieren können. Daher mal die Frage... was machst du anders als ich, denn scheinbar funktioniert das bei dir ja.

Vielleicht hab ich aber auch nur wieder die falschen Gedankengänge und/oder denke einfach zu kompliziert. Kannst du meinen Gedankenknoten vielleicht lösen?

BTW: Wenn ich die login.cgi von Hand nach ../ui/modules schiebe und chown auf LogAnalysis setze, läuft das SPK. Des Weiteren habe ich das SPK unter join-groupname: "log" installiert und im Vorfeld aus der Gruppe system sowie log mal den Benutzer LogAnalysis rausgeschmissen. Von daher... laufen tut das alles... leider aber nur mit manueller Nachhilfe.

 

[Tosoboso]

Dumm nur, das nur die authenticate.cgi über die Rechte 755 (rwxr-xr-x system) verfügt und somit während der SPK Insatallation umkopiert werden kann und entsprechende chown Rechte gesetzt werden können. Der login.cgi 550 (r-xr-x--- system) sowie der synowebapi 700 (rwx------ root) fehlt aber ein Lese- und/oder Ausführungsrecht, damit man die Dateien überhaupt bewegt bekommt.

Nein, du sollst die Datein in das SPK reinpacken, im package.tar in ui/modules via 7zip. Vorher natürlich via Konsole und sudo die Dateien in ein Synoverzeichnis kopieren und andere acls gebe, damit du von Windows drauf zu greifen kannst. Falls du diese schon in package.tgz hattest und mit dem user:group LogAnalysis:Log arbeitest, dann passt das. Du kannst natürlich die ACLS etwas anpassen auf 750.
-TosoBoso

 

[Tommes]

Ah, jetzt. Ja!
Irgendwie erschien mir dieses Vorgehen als "zu einfach" als das es funktionieren könnte. Zu meiner Verteidigung kann ich nur sagen, das du geschrieben hast...

(leider muss man bei Upgrades dies neu ausrollen)

... was ich so interpretiert habe, das ich besagte Dateien bei jedem schnüren eines SPKs, auf ein neues nach /ui/modules kopieren muss. Dann würde es sich anbieten, das über die /script Dateien (postinst etc.) zu lösen. Du meintest mit Upgrades aber wohl DSM-Upgrades! Wie auch immer....

Hab das alles mal richtig eingestellt und es scheint tatsächlich zu funktionieren. Vielen Dank (mal wieder) für deine Hilfe.

Ich bastel noch ein wenig rum und baue u.a. noch deine "Königsklasse" ein. Dann werde ich im LogAnalysis Thread meine Ergebnisse präsentieren und hoffen, das es bei allen anderen auch läuft.

Tommes

 

[Tosoboso]

Hi, cool.
Das mit Kopieren unter postinst könnte funktionieren, denn wenn man default run as package macht, dann ist doeser Teil der Gruppe System, hab ich gecheckt. Sonst mach man postinst als Teil von / run as system, es ist ja nur root verboten.
Das ist immer besser, als die Module mit ins SPK zu packen. Mit Upgrade meinte ich übrigens Synology Upgrades.
Du musst also nach jedem Upgrade dein Paket nochmals deüber bügeln, postinst läuft ja auch bei Upgrade und damit die Dateien pauschal erneueren, sonst sind die nicht binär kompatibel zur Api. Jedenfalls verweigert eine login.cgi von DSM-6 unter 7 den Dienst.
-TosoBoso

 

[Tommes]

Auch wenn das hier langsam ziemlich speziell wird und nicht unbedingt in diesen Thread gehört (ist das eigentlich schon off-topic?)...

Ich habe in der privilege dieses hier geschrieben....

{
    "defaults":{
        "run-as": "package"
    },
    "username": "LogAnalysis",
    "join-groupname": "log",
    "ctrl-script":[{
        "action": "postinst",
        "run-as": "package"
        }]
}

... und trotz das ich versuche postinst als run-as: package laufen zu lassen, erhalte ich bei der Installation des SPK folgenden Hinweis...

​

Auch wenn ich postinst als run-as: system laufen lasse, erhalte ich anschließend diese Meldung. Selbstredend das gleiche in grün auch bei root. Ich habe das Gefühl, das, sobald ich ein "ctrl-script" eintrage, verweigert mir das Paketzentrum die Installation des SPK.

Keine Ahnung ob ich vielleicht etwas falsch mache oder etwas übersehe (was wohl das Naheliegendste wäre), oder ob das nur geht, wenn Synology seine Hand über das SPK hält? Ich weiß es nicht...

 

[Tommes]

Ich hab da nochmal einen rausgehauen bezüglich LogAnalysis *klick*

 

[Axel64]

Was mir fehlt:

- In der Foto Vollbild Ansicht fehlt die Möglichkeit Thumbnails einzublenden (unten als Leiste)
- Der Karten Modus ist nicht mehr da, man kann nur noch den Geostandort als Text sehen.
- Lautstärke bei Videoclips wird nicht gespeichert und muss beim Durchschauen für jeden Clip angepasst werden.

Gerade Dein Hinweis zum Kartenmodus stimme ich uneingeschränkt zu, bin aber leider schon auf Beta DSM 7 unterwegs und habe mir eine Krücke gebaut um diesen wieder nutzen zu können.
Dann wollen wir mal hoffen das es auch beim Synology Photos Einzug hält ;-)
https://www.synology-forum.de/threads/dsm-7-beta-back-to-photo-station-wegen-kartenmodus.114695/

 

[Lichtograf]

Grüßt euch,

bin mir nicht ganz sicher, ob ich mit meinem Problem hier richtig bin: Installation eines (alten) Cloud-Station-Server Paketes unter DSM Beta 7.0.
Ich habe das Paket per Webbrowser runtergeladen und möchte es manuell im Paketzentrum installieren. Dort bricht es jedoch mit der Meldung ab:



Gibt es da ein Workaround o.ä. für? Danke für hilfreiche Antworten

(und das ganze nur, weil ich mit dem ach so tollen Drive nicht mehr mit meinem Handy in zwei Richtungen synchronisieren kann :-(

 

[Andy+]

Cloudstation ist nicht mehr lauffähig im DSM 7. Ersatz ist Drive. Es gibt besseres, wie z.B. Syncthing.

 

[geimist]

und das ganze nur, weil ich mit dem ach so tollen Drive nicht mehr mit meinem Handy in zwei Richtungen synchronisieren kann :-(

Synology sagt, dass du das nicht brauchst (Offlinesync).
Wenn du das anders siehst (ich auch), solltest du das Synology unbedingt wissen lassen.