Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Nov 2015 17:24:53 -0500
From:      Mark Heily <mark@heily.com>
To:        Dan Partelly <dan_partelly@rdsor.ro>
Cc:        freebsd-hackers@freebsd.org, Allan Jude <allanjude@freebsd.org>
Subject:   Re: libUCL / UCL as FreeBSD config question
Message-ID:  <CAGfo=8nMqnwM5%2Bys3oA5NXpMHP7wbW3jDPPS6wus7SjD57dcLQ@mail.gmail.com>
In-Reply-To: <CE91041D-0888-412D-BCBA-448A874D38BA@rdsor.ro>
References:  <5B598F72-C5DD-48FD-866D-F90E117D646E@rdsor.ro> <564F6118.5030702@freebsd.org> <5576AC9A-791F-4B52-9433-32D2806D35C9@rdsor.ro> <564F8E1F.8060600@freebsd.org> <CE91041D-0888-412D-BCBA-448A874D38BA@rdsor.ro>

next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 21, 2015 3:07 AM, "Dan Partelly" <dan_partelly@rdsor.ro> wrote:
>
>
> Absent the will to adopt a proper, fully transactional and atomic
mechanism of storing OS configuration,
> I would go back to the drawing board for a while.

The creation of a "proper" mechanism for storing OS configuration aligns
well with the mental roadmap that I have for the StateD project...

The current version of stated(8) provides the front end for a unified
configuration system with pub/sub notifications. The next incremental step
is to build the backend, and the initial implementation will just scrape
the configuration files in /etc and present them in a read-only fashion.

For the next major step, we could build an entirely new backend that uses
libUCL to provide read/write access to configuration settings. This access
would be mediated through stated(8) to provide history, transactions,
locking, atomicity, and notifications.

For example, imagine that one could change the host name and domain name
with this command:

     statectl set hostname=foo domain=bar.com

Behind the scenes, stateD would acquire a lock on appropriate current
configuration file(s), make a backup copy of the current state, use libucl
to modify the files to reflect the desired changes, unlock the file(s), and
generate notifications.

IMHO, it would be better for libucl to focus on being a general-purpose
library for parsing/generating configuration files, and have another layer
like stated(8) that manages things like concurrency and transactions.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGfo=8nMqnwM5%2Bys3oA5NXpMHP7wbW3jDPPS6wus7SjD57dcLQ>