Re: [Freedombox-discuss] FBx config mgmt update
On Mon, 23 Jul 2012, bnewb...@robocracy.org wrote: I should probably give the code a one-over and include a HOWTO; I'll do this tomorrow (tuesday). Added a HOWTO and some other improvements; updated the pull request: https://github.com/jvasile/Plinth/pull/2 -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
On Sun, 22 Jul 2012, Nick M. Daly wrote: Bryan, is this ready for me to add to the weekly images? This might solve FreedomBuddy's OpenVPN service control issues. It's waiting for review/consensus/merge, but at this point there have been no complaints so it's probably good to go? Does Plinth or the freedombox foundation have licensing policy or guidelines? Should I delegate copyright to the foundation? Sort of a mountain over a molehill for this patch. I should probably give the code a one-over and include a HOWTO; I'll do this tomorrow (tuesday). Does anybody have thoughts on logical error handling behavior? Some of the existing Plinth code (eg, hostname changer) would try to revert changes when they failed; i'm not sure if that behavior should be implemented at the exmachina (library/wrapper) level or left to application logic. -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
On Mon, Jul 23, 2012 at 8:18 AM, bnewb...@robocracy.org wrote: On Sun, 22 Jul 2012, Nick M. Daly wrote: Bryan, is this ready for me to add to the weekly images? This might solve FreedomBuddy's OpenVPN service control issues. It's waiting for review/consensus/merge, but at this point there have been no complaints so it's probably good to go? I'll wait for review and for James to merge it upstream. I'll also look it over closely before adding it to the weekly images. Does Plinth or the freedombox foundation have licensing policy or guidelines? Should I delegate copyright to the foundation? Sort of a mountain over a molehill for this patch. Plinth is AGPL3, so I just AGPL3ed FreedomBuddy. I've heard nothing about copyright reassignment or contributor agreements, so I'm reserving my own copyrights for now, until asked otherwise. I should probably give the code a one-over and include a HOWTO; I'll do this tomorrow (tuesday). Does anybody have thoughts on logical error handling behavior? Some of the existing Plinth code (eg, hostname changer) would try to revert changes when they failed; i'm not sure if that behavior should be implemented at the exmachina (library/wrapper) level or left to application logic. Thinking about this, I'd like to know how Ex does two things: 1. Whether changes are atomic (how do we prevent the system from seeing a semi-changed state?). 2. Whether failed changes aren't implemented. It seems like the least surprising behavior would be: if Ex can't save the changes, it rolls them back and raises an error. That way, the system's never left in an undefined state, and the controlling application can decide whether to give it another go or just bail. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
On Mon, 23 Jul 2012, Nick Daly wrote: Does anybody have thoughts on logical error handling behavior? Some of the existing Plinth code (eg, hostname changer) would try to revert changes when they failed; i'm not sure if that behavior should be implemented at the exmachina (library/wrapper) level or left to application logic. Thinking about this, I'd like to know how Ex does two things: 1. Whether changes are atomic (how do we prevent the system from seeing a semi-changed state?). Currently this is left to the application logic (separate set/save calls). I'll need to check if Augeas rolls back commits to multiple files if one of the files fails. 2. Whether failed changes aren't implemented. It seems like the least surprising behavior would be: if Ex can't save the changes, it rolls them back and raises an error. That way, the system's never left in an undefined state, and the controlling application can decide whether to give it another go or just bail. I meant at a higher level: the configuration file is saved, but restarting services depending on that configuration file fails. The easy solution with minimal surprise is to bubble up the service restart error message and wait for the user to reconfigure before restarting the service. Rolling back changes could result in large amounts of user-entered data being lost because of a small typo. Some firmwares (pfSense) also implement a test configuration feature which reverts new changes after two minutes unless they are re-confirmed; this helps prevent bricking or user lockout due to misconfiguration. I think this is overkill for now. -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
On Sun, 15 Jul 2012 00:24:45 -0400 (EDT), bnewb...@robocracy.org wrote: Forgot to update this list, but I submitted a pull request to the Plinth repository: https://github.com/jvasile/Plinth/pull/2 The core of the changes I made are also available in a separate repository: https://github.com/bnewbold/exmachina http://git.bnewbold.net/?p=exmachina.git;a=summary The scheme is pretty complicated and the init.d script is ugly, but the end result is privilege separation and less complicated configuration setting code. I implemented hostname changing as an example, but (ironically?) changing the timezone with /etc/timezone is not supported by augeas out of the box (that I could find). augeas added configuration file lenses for openvpn configuration some years ago, but I haven't tested them. Bryan, is this ready for me to add to the weekly images? This might solve FreedomBuddy's OpenVPN service control issues. Also, I took a look at the ExMachinaHandler, and you could simplify it a lot by making it inherit from the Augeas class as well, there'd be no need for the wrappers. Otherwise, you can probably do some fancy magic with getattribute. I'd duckduck for something on pass through, but I haven't figured out how to prevent it from recursing infinitely when the wrapped object doesn't have the attribute (because you're calling getattribute on the current object from within its getattribute function). Nick pgpRkpBEqk5Vy.pgp Description: PGP signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
Forgot to update this list, but I submitted a pull request to the Plinth repository: https://github.com/jvasile/Plinth/pull/2 The core of the changes I made are also available in a separate repository: https://github.com/bnewbold/exmachina http://git.bnewbold.net/?p=exmachina.git;a=summary The scheme is pretty complicated and the init.d script is ugly, but the end result is privilege separation and less complicated configuration setting code. I implemented hostname changing as an example, but (ironically?) changing the timezone with /etc/timezone is not supported by augeas out of the box (that I could find). augeas added configuration file lenses for openvpn configuration some years ago, but I haven't tested them. -bryan On Tue, 10 Jul 2012, bnewb...@robocracy.org wrote: Spoke with James and a few others here at the OpenITP event, notes and a rought plan are below. Some of this feels like reinventing the wheel; a future/mature implementation might use: D-Bus for message passing, PolicyKit for access control, Augeas for read/write or building off ubus (IPC from OpenWrt) and netif (network interface configuration from OpenWrt), extending with augeas configuration or libassuan (from GPG) to handle narrow scope trusted IPC But for now i'm just going to bang something out so that plinth can use the python-augeas interface through an access controlled unix domain pipe. - requirements/compromises: - scope of configuration middleware is regular system files, mostly in /etc (no user/identity management) - files should be edited in place - local changes should be respected - single root/wheel permissions level for reading, writing, and applying changes - configuration versioning taken as a seperate problem from editing - client code (aka plinth) is responsible for semantic/logical validation, and service restarts new program: exmachina: hand of root configuration management daemon which runs with root permissions, listens on a unix domain socket with access controlled by filesystem permissions. uses a very simple api to provide access to augeas configuration file editing and service restarts. plinth/apache, running not-as-root, is passed access at startup (ENV vars? file handle pass?) single-thread, serializes edits simple, written in python (for now), including python client library which replicates python-augeas interface extra features (somedaymaybe): general purpose ncurses, gui, or web interface no-downtime reloads of daemon via HUP (a la nginx) fine-grain ACL dpkg installation general purpose features: process execution, package installation, file read/write -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
[Freedombox-discuss] FBx config mgmt update
Spoke with James and a few others here at the OpenITP event, notes and a rought plan are below. Some of this feels like reinventing the wheel; a future/mature implementation might use: D-Bus for message passing, PolicyKit for access control, Augeas for read/write or building off ubus (IPC from OpenWrt) and netif (network interface configuration from OpenWrt), extending with augeas configuration or libassuan (from GPG) to handle narrow scope trusted IPC But for now i'm just going to bang something out so that plinth can use the python-augeas interface through an access controlled unix domain pipe. - requirements/compromises: - scope of configuration middleware is regular system files, mostly in /etc (no user/identity management) - files should be edited in place - local changes should be respected - single root/wheel permissions level for reading, writing, and applying changes - configuration versioning taken as a seperate problem from editing - client code (aka plinth) is responsible for semantic/logical validation, and service restarts new program: exmachina: hand of root configuration management daemon which runs with root permissions, listens on a unix domain socket with access controlled by filesystem permissions. uses a very simple api to provide access to augeas configuration file editing and service restarts. plinth/apache, running not-as-root, is passed access at startup (ENV vars? file handle pass?) single-thread, serializes edits simple, written in python (for now), including python client library which replicates python-augeas interface extra features (somedaymaybe): general purpose ncurses, gui, or web interface no-downtime reloads of daemon via HUP (a la nginx) fine-grain ACL dpkg installation general purpose features: process execution, package installation, file read/write -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
Also, just to be explicit, this would provide process separation, but does not address local user authentication or access control. Eg, in this scheme plinth would have permissions to edit all configuration files and would need to authenticate users for access control on it's own (it doesn't do this yet IIRC). What I would like is for the plinth process and the plinth process alone to have access to the unix domain socket. One way to do this would be to create a new group and use file system permissions, but yet another user/group seems like a bad idea. Another way would be to have the (root permissions) /etc/init.d/plinth script generate a secret key, register it with the running exmachina process, and pass that secret key to plinth which would use it to authenticate every RPC call over the pipe. This makes me a bit queasy because I know web applications often make accessible or dump their full environment variables and local scope as a debug feature; surely debug mode for plinth will be disabled, but still... -bryan On Tue, 10 Jul 2012, bnewb...@robocracy.org wrote: Spoke with James and a few others here at the OpenITP event, notes and a rought plan are below. Some of this feels like reinventing the wheel; a future/mature implementation might use: D-Bus for message passing, PolicyKit for access control, Augeas for read/write or building off ubus (IPC from OpenWrt) and netif (network interface configuration from OpenWrt), extending with augeas configuration or libassuan (from GPG) to handle narrow scope trusted IPC But for now i'm just going to bang something out so that plinth can use the python-augeas interface through an access controlled unix domain pipe. - requirements/compromises: - scope of configuration middleware is regular system files, mostly in /etc (no user/identity management) - files should be edited in place - local changes should be respected - single root/wheel permissions level for reading, writing, and applying changes - configuration versioning taken as a seperate problem from editing - client code (aka plinth) is responsible for semantic/logical validation, and service restarts new program: exmachina: hand of root configuration management daemon which runs with root permissions, listens on a unix domain socket with access controlled by filesystem permissions. uses a very simple api to provide access to augeas configuration file editing and service restarts. plinth/apache, running not-as-root, is passed access at startup (ENV vars? file handle pass?) single-thread, serializes edits simple, written in python (for now), including python client library which replicates python-augeas interface extra features (somedaymaybe): general purpose ncurses, gui, or web interface no-downtime reloads of daemon via HUP (a la nginx) fine-grain ACL dpkg installation general purpose features: process execution, package installation, file read/write -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
