(changed subject) On Mon, Jun 01, 2015 at 12:49:31PM -0400, Thompson, David wrote: > > Are you envisaging something like that? Something that reruns state > > and updates? It is a lot more complicated because you need a way to > > define state, modify files, allow for transaction and roll-back. > > Ideally the system should execute in parallel (for speed) and be > > ordered (i.e. if two methods change the same file the order matters). > > BTW cfruby lacks transactions and parallel execution, we could start > > without. > > Sort of yes, sort of no. What you are describing sounds quite > imperative.
Right. > In Guix, if we were to re-deploy a configuration to a > running remote system, we'd do the equivalent of what 'guix system > reconfigure' does now for local GuixSD machines: an atomic update of > the current system (changing the /run/current-system symlink). 'guix > deploy' cannot possibly do a good job of managing non-GuixSD systems > that just happen to run Guix. I think it would be better to use the > existing configuration management tools for that. OK, this sounds exciting and could certainly work well. I guess hosts.allow would be an input to an sshd builder, right, so different configurations become their own subtrees in the store. I like that idea. hosts.allow (as a complication) is actually part of tcp-wrappers so it would have to be configured for all tools that it addresses on a machine. I presume hosts.allow would be stored in the store too. > > The first step is to define state by creating 'classes' of machines. > > One class could be deploy 'sshd with IP restriction'. That would be a > > good use case. > > Are you proposing that we add a formal concept of "classes" in Guix or > is this just to illustrate an idea? If the former, I think that pure > functions that return <operating-system> objects is far more powerful > than a primitive class labeling system. > > Hope this helps clarify some things. Thoughts? I am not too clear on the OS objects, but maybe I should play with deploy first. I guess what you are saying is that a machine configuration is generated by its s-expression(s) so we don't need classes. Wherever these s-expressions come from is an implementation issue. Right? Pj.
