Ich habe ein Programm geschrieben, das als Session-Dienst über dbus läuft.
Ich wollte es als Systemdienst ausführen lassen (indem ich einen dbus.SystemBus-Bus-Namen erstelle), wenn es von root (uid 0) ausgeführt wird.
Ich versuche, für dbus.SystemBus auszuführen, was ich derzeit für dbus.SessionBus ausführen, aber einen Richtlinienfehler erhalten.
Der Code (Python aber es ist nicht wirklich wichtig), gelöscht von allem unnötigen, ich renne ist dies:
und erhalten:
%Vor% Am einfachsten geht es mit dem obigen Beispiel, indem Sie /etc/dbus-1/system.conf bearbeiten und die folgende Zeile hinzufügen:
Ich bin Teil eines kleinen Teams (4 - 5), die an einem Embedded-Linux-Projekt arbeiten. Wir verwenden Buildroot und die Linaro Toolchain, um für unser Ziel zu bauen. Wir verwenden git für die Versionskontrolle und Jenkins für nächtliche Builds.
Das ist unser erster Versuch bei einem Projekt wie diesem und es ist mir nicht gelungen, Ressourcen zu finden, die Modelle für die Entwicklung mit dieser Art von Umgebung beschreiben.
Im Moment, nach einem nächtlichen Build, erstelle ich einen Tarball des Buildroot 'output' -Verzeichnisses, das die U-Boot-Images und das Root-Dateisystem enthält. Dies kann direkt von der Jenkins 'Archiv' Seite für den letzten erfolgreichen Build heruntergeladen werden.
Einige von uns werden an der Entwicklung auf niedrigerer Ebene arbeiten und einige an der Benutzerraumentwicklung (QT). Unser Problem ist, zu entscheiden, welcher der effizienteste / rationellste Ansatz die Entwicklung in einer solchen Umgebung ist, da die Menschen in verschiedenen Bereichen innerhalb des Projektumfangs arbeiten werden. Die Userland-Leute könnten den Tarball mit allem herunterladen und ihre Anwendungen in die Rfs integrieren, um auf dem Board zu laufen und zu debuggen, aber wie sollen wir mit der Arbeit auf der unteren Ebene der Entwicklung umgehen? Grundsätzlich, wie sollten wir die Artefakte an das Team verteilen? Ich schätze alle Gedanken sehr.
Ich habe kürzlich einige Zeit damit verbracht, die Build-Umgebung für ein OpenEmbedded-basiertes Linux-Projekt neu zu strukturieren. Ich habe keine direkten Erfahrungen mit Buildroot, aber ich erwarte, dass OpenEmbedded dem, was Sie verwenden, ähnlich ist. Ich werde mein Setup beschreiben und mit etwas Glück finden Sie hier etwas Nützliches ...
Es gibt drei Softwarekomponenten, die separat installiert werden können (d. h. unabhängig voneinander): der Bootloader (u-boot); der Kernel (Linux); und das Dateisystem-Image. Unser Endprodukt wird mit einem verpackten Release dieser drei Komponenten ausgeliefert. Das heißt, eine Version von U-Boot, Linux und Dateisystem-Image, die QA-getestet wurden und von denen bekannt ist, dass sie zusammenarbeiten. Es ist jedoch möglich, eine der Komponenten unabhängig zu aktualisieren (z. B. ein neues Kernel-Image zu installieren), um eine Kombination von Softwarekomponenten zu erstellen, die nicht zusammen getestet wurden.
Dieses Problem besteht auch für Benutzerbereichsanwendungen. Sobald ein Dateisystemimage in das Ziel installiert wurde, ist es möglich, einen oder mehrere Benutzerraum-Binärdateien unabhängig von anderen Dateisystemobjekten zu aktualisieren (vorausgesetzt, Ihr Dateisystem ist nicht schreibgeschützt). Woher wissen Sie, dass die spezifische Kombination von Benutzer-Space-Anwendungen, die jetzt installiert sind, zusammenarbeiten kann? Wie kann ich sicher sein, dass die Kombination von Binärdateien, die in dieser bestimmten Einheit laufen, dieselbe Kombination von Binärdateien ist, die QA-zertifiziert wurden? Woher weiß ich, welche "Version" die Software ist?
Das andere Problem, das ich lösen musste, das gleiche Problem, das Sie in Ihrer Frage beschrieben haben, ist, wie man Entwicklern, die an verschiedenen Teilen des Software-Stacks arbeiten (Kernel, Root-Dateisystem, Qt-Apps usw.), zusammenarbeiten kann.
Ich habe dies und das "Version" -Problem folgendermaßen angesprochen:
Das Speichern der root-Dateisystem- und System-Stammdateien des Ziels in einem git-Repository hat mich anfangs in die falsche Richtung gerammt (Speichern von Ausgabedateien in der Versionskontrolle, was!?!), bietet aber folgende Vorteile:
Die Verzeichnisstruktur sieht ungefähr so aus (einige Namen wurden geändert, um Unschuldige zu schützen):
%Vor%Jedes markierte Verzeichnis [*] ist ein Git-Repository und jedes Git-Repository ist ein Submodul seines Elternteils.
Die Build-Umgebung wird von einem Makefile der obersten Ebene initialisiert, das im Wesentlichen eine rekursive %code% und %code% verwendet. Alle Entwickler würden tun:
%Vor%Ein User-Space-Entwickler kann dann sofort erstellen:
%Vor%Der Maintainer des Dateisystems kann rootfs aktualisieren:
%Vor%Vom Makefile der obersten Ebene ( %code% ) ist es möglich, alle Softwarekomponenten (Kernel, U-Boot, Dateisystem-Image) zu erstellen. Mit den folgenden git-Befehlen exportiert das Makefile an alle Sub-make-Prozesse eine einzige Umgebungsvariable (z. B. %code% ), die die aktuelle Softwareversion beschreibt. Die Version ist entweder ein Tag aus dem Git-Repository oder ein SHA (z. B. %code% , %code% oder %code% ).
%Vor%Wenn sogar eine einzelne Datei in einem der Unterverzeichnisse des Projekts geändert wurde, dann ist %code% immer %code% . Diese einzelne Variable %code% wird dann als Kompilierzeitkonstante an alle Builds übergeben (U-Boot-, Kernel-, Userspace-Anwendungen usw.).
Zur Laufzeit akkumuliert eine benutzerdefinierte Benutzerbereichsanwendung die %code% -Werte aller Komponenten, und wenn sie alle denselben Wert melden, wird diese Zeichenfolge zur offiziellen Version, die vom Produkt gemeldet wird. Wenn sich auch nur ein %code% -Wert von den anderen unterscheidet, dann wurde der Software-Stack nicht aus dem gleichen SHA der obersten Ebene erstellt und kann nicht in die Wildnis entlassen werden (zu QA zum Testen, zur Produktion für die Herstellung usw.).
Wenn eine Softwarekomponente nicht aus dem Makefile der obersten Ebene (z. B. %code% ) erstellt wird, ist die %code% für diese Komponente undefiniert und der resultierende Softwarestapel für "nur interne Verwendung". Das heißt, eine "Freigabe" aller Softwarekomponenten kann nur durch den Aufbau aus dem Makefile der obersten Ebene erfolgen.
Als Referenz meldet Linux %code% über eine benutzerdefinierte Datei in procfs, u-boot-Berichte über die Linux-Befehlszeile ( %code% ) und jede Benutzerbereichsanwendung über Interprozesskommunikation.
Ein Vorbehalt.Ich habe diese Build-Umgebung erst vor einem Monat entwickelt, kann also keine Behauptungen für ihre Robustheit machen, aber für den Moment scheint es zusammenzuhalten ...
Wenn Sie bestimmte Fragen oder Punkte haben, die Sie klären möchten, werde ich gerne meine Antwort aktualisieren.