Update neu ändert fhem.pl Berechtigung

[Billy]

Hallo Rudi,

habe meine prod. System mal auf den neuesten Stand gebracht und festgestellt, dass update neu die Permissions von
fhem.pl nach jedem update auf 0644 / rw-r--r-- setzt.

Das war m.E. vorher nicht so. Da ich aber als Berechtigung 0744 / rwxr--r-- brauche muss ich nach jedem update manuell eingreifen.

Wo kann ich drehen, dass update die gesetzte Berechtigung nicht mehr überschreibt?

Gruß Billy

[betateilchen]

Nur mal so interessehalber: Wozu um alles in der Welt brauchst Du das x-Flag bei fhem.pl?

[Billy]

Diese Frage habe ich erwartet.

Ganz einfach, weil ich fhem mit den Daten aus meinem Solar- Heizungsregler füttere. ( alle 3 Minuten)
Kleiner Code Auszug anbei.

Code Auswählen Erweitern

sub write {
  my ($self,$sensorValues,$sensors) = @_;

  return 0 unless $self->openLog();

  my $fhemCall = "$self->{fhemCall} \"";

  foreach my $device (sort(keys( %{$sensors->{data}}))){
    foreach my $sensor (@{$sensors->{data}->{$device}}) {
      my $output = @{$sensorValues->{output}}[$sensor];
      printf {$self->{fhemLog}} "$self->{timestamp} $device d%02d: $output\n",$sensor;
      $fhemCall .= "set D$sensor $output; ";
    }
  }

  foreach my $device (sort(keys(%{$sensors->{temp}}))) {
    foreach my $sensor (@{$sensors->{temp}->{$device}}) {
      my $temperature = @{$sensorValues->{temperature}}[$sensor];
      printf {$self->{fhemLog}} "$self->{timestamp} $device t%02d: $temperature\n",$sensor;
      $fhemCall .= "set T$sensor $temperature; ";
    }
  }

Für diesen Systemaufruf brauchts halt diese Berechtigung.
Zufrieden?
Billy

[betateilchen]

Ganz einfach, weil ich fhem mit den Daten aus meinem Solar- Heizungsregler füttere. ( alle 3 Minuten)
...
Zufrieden?

Nö. Das ist für mich kein Grund. Deine Aufgabenstellung kann man auch anders lösen.

[Billy]

No comment!
Billy

[betateilchen]

Das dachte ich mir.

Wenn Du unbedingt den Holzweg weitergehen willst: Definiere Dir einen cmdalias für update, der nach Abschluss des Updates die Berechtigungen neu setzt.

[rudolfkoenig]

@Billy: ich konnte aus deinem Beispiel nicht nachvollziehen, wieso du das x-flag benoetigst.

Das x-flag ist notwendig, wenn man darauf besteht, dass man fhem.pl direkt aufrufen kann (./fhem.pl <argumente>), und nicht ueber perl (perl fhem.pl <argumente>).
Ich bin noch nicht ueberzeugt, dass diese zusaetzliche Moeglichkeit mir Wert ist ein paar Zeilen Extra-Code (mit Ausnahme fuer Windows) in update.pm einzufuehren. Fuer die, die darauf bestehen, gibt es Umwege, wie betateilchen das schon gezeigt hat.

[Billy]

@Billy: ich konnte aus deinem Beispiel nicht nachvollziehen, wieso du das x-flag benoetigst.

Das x-flag ist notwendig, wenn man darauf besteht, dass man fhem.pl direkt aufrufen kann (./fhem.pl <argumente>), und nicht ueber perl (perl fhem.pl <argumente>).

Stimmt, habe das mal auf der Konsole getestet, damit habe ich ja die gewünschte einfache Lösung.
Wenn ich von der Console bei (0644) --> /opt/fhem/fhem.pl 7072 "set T1 75" aufrufe,
                                                                 Ergebnis -->  -bash: /opt/fhem/fhem.pl: Permission denied

Wenn ich von der Console bei (0644) --> perl /opt/fhem/fhem.pl 7072 "set T1 75" aufrufe,
                                                                     dann wird der Befehl problemlos ausgeführt und in FHEM T1 75 gesetzt.
Also Danke für den Hinweis wieder was hinzugelernt.

Gruß Billy

[betateilchen]

auf die schräge Idee, die fhem.pl direkt ausführen zu wollen, bin ich noch nie gekommen :8

Aber ich bin doch sehr beruhigt, dass mein Gedanke, dass man das x nicht braucht, durchaus nicht so sehr falsch war.

[justme1968]

so schräg ist die idee nicht sondern standard unix praxis für scriptsprachen und der grund für die #! syntax am anfang der files.

unabhängig davon ob man es 'braucht' ist es sehr praktisch wenn man sich daran gewöhnt hat. auch in verbindung mit einer passend konfigurierten tab autocompletion in der shell.

wie bei vielen gewohnheiten und geschmacksfragen könnte man da wunderbar deüber streiten aber schräg ist es ganz sicher nicht nur weil du es nicht kennst oder benutzt.

ich starte fhem auf den entwicklungssystemen schon immer nur so. das x flag das fhem.pl im svn hat ist vermutlich auch nicht von alleine entstanden.

wenn man in ppdate statt mv ein copy zum sichern der files verwenden würde hätte man in fehlerfall das zurück moven gespart, den disk full fehler abgefangen und keine probleme falls das restore dir auf einem anderen filesystem liegt.

ganz nebenbei würden die permissons erhalten bleiben.

gruß
  andre

[rudolfkoenig]

Dafuer waere der Zeitstempel der gesicherten/alten Datei alle. Und falls man die Sicherung auf eine andere Partition macht, und lokal jemand (FHEM?) die Platte gerade vollschreibt, dann kann ein update die Installation ruinieren.

Ich sehe aber auch Vorteile von x-bit: damit kann man fhem.pl in Pfad aufnehmen, und ohne Pfadangabe fhem.pl fuer client Befehle ausfuehren.

Fazit: Man kann nie jedem recht machen.

[Billy]

Fazit: Man kann nie jedem recht machen.

Schönes Schlusswort.

Billy

[betateilchen]

Wenn ich überlege, wieviele Probleme hier im Forum schon alleine dadurch entstehen, dass User über Null-Grundlagen im Bereich Linux verfügen, möchte ich gar nicht darüber nachdenken, was passieren würde, wenn man jetzt auch noch mehrere Möglichkeiten schaffen würde, fhem an sich zu starten.

Und die User, die wissen, worum es geht, haben mMn keinerlei Problem damit, dass das x-Flag nicht automatisch gesetzt wird. Von alleine würde ja die fhem.pl auch nicht in irgendeine Pfadangabe wandern, um direkt aufgerufen werden zu können.

Mein Fazit: Die momentane Lösung ist ein guter Kompromiss zwischen "Alltagstauglichkeit für unbedarfte Anwender" und "Wunschkonfiguration für Linux-Kenner". Die erste Gruppe wird ohnehin nie darüber stolpern, dass das x-Flag nicht gesetzt ist.