Warum nutzt IOBroker ACLs?
-
Leider steht da nicht exakt warum setfacl notwendig ist
As said meine Erinnerung sagt:
Iobroker wird als User iobroker ausgeführt. Daher muss so wie npm gestrickt ist und funktioniert alles sauber dem iob User gehören.
Wenn man jetzt aber npm Befehle als zb pi User ausführt entsteht ein bunter User owner mix. Scheinbar ist npm dann aber leider egal irgendwie wie Gruppen und so gestrickt sind die sowas abfangen sollten und dann knallt es bei npm Installationen von Adaptern mit wilden permission issues. Das mit acl war der einzige Weg den wir gefunden haben mit dem das klappt.
Npm ist bei bestimmten Dingen eine bitch und kochen da ihr süppchen
-
Ps: acl sind drin seit dem großen rewrite am 20.1.2019
-
@apollon77 sagte in Warum nutzt IOBroker ACLs?:
Wenn man jetzt aber npm Befehle als zb pi User ausführt entsteht ein bunter User owner mix.
Noch schlimmer: mit
sudooder alsroot
Die ACLs waren der einzige (uns bekannte) Weg sicher zu stellen, dass egal was unbedarfte User da auf der Kommandozeile anstellen oder wie alt die Videotutorials
sind, denen sie folgen, dass ioBroker trotzdem normal funktionieren kann. -
Hi
Da ich beide Seiten ein wenig kenne will ich mich hier trotz Urlaub und damit Einschränkung auf Handyzugriff zu Wort melden.
RaspiBackup ist ein tolles Projekt mit dem man den gesammten pi einfach backuppen kann. (Und auch wieder restaurieren). Iob backup sehe ich als paralelles tool weil iob backup mir bei einem crash (soweit ich weiss) nicht das gesammte rspian incl. Setup des raspi restaurieren kann. Natürlich ist rein für die iob daten iob backup erste wahl. Aber ich hab am pi noch andere dinge laufen die mir rasoiBackup mitsichert. Dank rsync erfolgt das sehr platzsparend am remote nas.
Leider versteht synology keine acls. Das ist v synology so confirmed.
Ich lösche mittlerweile alle acls vorab raus. Bisher hab ich damit keine probleme feststellen können. Die option beim rsync kannte ich bis jetzt nicht, werd mir das in bezug auf raspiBackup ansehen.
Was die acls bei iob sollen wollte ich auch schon fragen. Der Grund wurde hier ja nun erläutert. Im prinzip sollte es auch ohne acls gehen. S bit und group rechte bieten da auch möglichkeiten. Aber ich versteh dass es 1000 Möglichkeiten gibt dann die fileprotections abzuschiessen.
Ich würde hier eher bei raspi Backup ansetzen. Wenn rsync mit -A ausreicht acls zu ignorieren dann könnte man das dort als standard setzen. Das mann bei einem full restore noch dinge nacharbeiten muss sollte jedem klar sein. Ev kann man höchstens überlegen den iob fixer automatisch bei problemen zu starten - also beim start von iob mal nen scan mit find auf falsche owner bzw protections machen und wenn was gefunden wird den fixer laufen lassen. Aber das ist wieder systemabhängig und unter windows andrrs als unter linux. Ergo kann ich nicht sagen ob das denkbar ist.
McM
-
@mcm57 said in Warum nutzt IOBroker ACLs?:
Ich würde hier eher bei raspi Backup ansetzen. Wenn rsync mit -A ausreicht acls zu ignorieren dann könnte man das dort als standard setzen.
Ich habe auch laenger damit gehadert ob nun die rsync Optione -A Standard ist oder nicht. Letztendlich habe ich es doch mit aufgenommen denn raspiBackup soll ein Backup welches eine identische Kopie des aktuellen System ist erstellen und dazu gehoeren auch ACLs. Solange eine lokale Backuppartition oder auch eine nfs3 gemountete Backuppartition (leider nicht bei Synology/QNAP) genutzt wird werden auch ACLs gesichert.
ich denke ich werde eine weitere Webseite bei mir erstellen wo Tipps wie man mit bestimmten Anwendungen mit raspiBackup umgehen soll beschrieben sind. IOBroker ist nicht das einzige Tool was ACLs nutzt und bei Synology und QNAP Probleme macht.
Ich habe wie gesagt keine Ahnung von IOBroker. Was ich jetzt mittlerweile gelernt habe ist dass es wohl Sinn macht die -A Option zu entfernen dass keine ACLs gesichert werden und nach dem Restore noch ein Postprocessingstep durchgefuehrt werden sollte um die ACLs wieder zu setzen. Was sollte ich da genau schreiben? Waere nett wenn ich einen Vorschlag dazu von Euch IOBroker Kennern bekommen wuerde was ich bei mir zum IOBroker dokumentieren sollte.
Da in der neuesten Release 0.6.7 auch Restoreplugins unterstuetzt sind koennte man auch ein Restoreplugin fuer IOBroker schreiben welches den o.g. Postprocessingstep automatisch ausfuehrt
-
@alcalzone said in Warum nutzt IOBroker ACLs?:
Die ACLs waren der einzige (uns bekannte) Weg sicher zu stellen, dass egal was unbedarfte User da auf der Kommandozeile anstellen oder wie alt die Videotutorials sind, denen sie folgen, dass ioBroker trotzdem normal funktionieren kann.
Ich kann mit Euch fuehlen. Wenn man auf andere Tools und deren Befindlichkeiten Ruecksicht nehmen muss ist man froh wenn man das geschafft hat. Darum will ich auch in keiner Weise an den ACLs ruetteln. Ich dachte nur ich koennte von Euch etwas ueber ACLs lernen
-
Kennst du den Artikel von stka?
-
@thomas-braun said in Warum nutzt IOBroker ACLs?:
Kennst du den Artikel von stka?
Stefan kenne ich - aber nicht diesen Artikel. Sehr interessant ist dass man ACLs in einer Datei sichern und wieder restoren kann wenn das Dateisystem keine ACLs unterstuetzt. Das waere z.B. ein Workaround den ich in raspiBackup einbauen koennte. Beim Backup wird eine ACL Sicherungsdatei im Backup erstellt und beim Restore wieder restored. Ich werde mir das mal genauer ansehen.
-
@framp Also effektv sollte der ioBroker fixer (ausgeführt mittels "iob fix") das richteh und der muss nach restore und vor restart ausgeführt werden. Wäre auch das was das Plugin machen müsste.
-
@apollon77 Ok. Dann werde ich das so dokumentieren. Wenn ich dann rausgefunden habe wie man ACLs allgemein mit raspiBackup sichern kann auch wenn das Zielbackupsystem das nicht unterstuetzt und in einem der naechsten Releases implementiert habe nehme ich das wieder raus.
Je nachdem wie lange das dauert und wieviel Zeit ich habe schreibe ich vielleicht bis dahin auch noch ein Restoreplugin. Das ist nur eine Zeile Code. Ist iob bei IOBroker im Path verfuegbar oder muss man das als bestimmter User oder sonstwie speziell aufrufen?
-
echad@chet:~ $ which iobroker /usr/bin/iobroker echad@chet:~ $ ls -la /usr/bin/iobroker lrwxrwxrwx 1 root root 22 May 17 19:03 /usr/bin/iobroker -> /opt/iobroker/iobroker echad@chet:~ $ ls -la /opt/iobroker/iobroker -rwxr-xr-x+ 1 iobroker iobroker 309 May 17 19:03 /opt/iobroker/iobroker echad@chet:~ $ -
@framp was Thomas schreibt. „iob“ ist nur alias für „iobroker“. Müsste beides gehen. Ganz sicher auch für ältere Installationen ist es „iobroker“
-
Vielen Dank fuer Eure Hinweise.
Ich habe eben diese Seite erstellt und beschrieben was Ihr mir erklaert habt. Zusaetzlich habe ich noch aufgenommen dass man den IOBroker vor dem Backup stoppen und anschliessend wieder starten sollte. Falls die Beschreibung nicht OK ist lasst es mich bitte wissen und ich updated die Befehle entsprechend.
-
@framp Text passt! Danke!
-
Ich lösche immer VOR dem Raspi Backup die acls:
sudo setfacl -bR /opt/iobrokerBisher konnte ich kein negativen Auswirkungen feststellen. Das soll aber keine Empfehlung sein ioB so zu betrieben.
Ev. wäre folgender Ansatz in Verbindung mit raspiBackup sinnvoll:
a) iobroker stop
b) sudo setfacl -bR /opt/iobroker
c) <execute raspiBackup>
d) iobroker fix
e) iobroker startDa (zumindest ich) sowieso das nfs warpper scrip für raspiBackup verwende (bzw. eine leicht erweiterte Version die das Synology startet und das nfs share mounted) habe ich diese Scripte dort integriert.
Damit sollte das Backup nicht wegen ioBroker ACLs scheitern - aber auch keine anderen Anwendungen unvollständig sichern (sprich: wenn noch eine Anwendung ACLs setzt, dann würde das auffallen und nicht einfach im Backup fehlen.
-
@mcm57 Vielen Dank fuer Deine Hinweise. Jetzt stellt sich natuerlich die Frage ob ich das auf meiner Seite so dokumentieren sollte
