libUCL / UCL as FreeBSD config question

[Allan Jude]

On 2015-11-18 02:55, Dan Partelly wrote:
> Hi all,
> 
> 
> is LibUCL able to read in memory a UCL key-value database , modify it in various ways :
> 
> 1. Add a new key-value pair
> 2. Modify the value of a value
> 
> and serialise the modified database back to disk ?
> 
> Or it is designed only a one way / read-only configuration mechanism ? 
> 
> The reason Im asking is this: 
> 
> if UCL becomes the new config mechanism of FreeBSD, does it brings any other advantage 
> than an easy to read and humanly write format ? Would this library/language be usable in 
> any other way in system configuration — apart from autoexec.bat way  —> use command line tool
>  to read key-vaule , filter it with some tool back to plain **text** and feed it to a command line utility
>  from FreeBSD base ? 
> 
> Let’s say one writes a network config daemon to handle network configuration, and expose network 
> configuration (like interface management, route management, DHCP bindings and so on), which 
> exposes all this functionality to the rest of the system through IPC. Now, let’s say , a simple client
> modifies the IP address of a certain interface, or host name or whatever, and in process modifying the
> corresponding  key-value in memory, in addition to sending the IOCTL to change ip address for the interface 
> to the kernel.
> 
> Is lib UCL able to serialise this change back to the file which backups up the database  ? If it is , all is dandy, 
> If it is not, is is this feature easy to implement in libUCL , without being a hack, or libUCL design was  read only 
> from start, thing  which  would make serialisation hard to implement cleanly ?
> 
> 
> 
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 

Basically, libucl parses the configuration from the file, and creates
the in-memory objects.

You then have an API to manipulate the objects, like add new key-value
pairs, push/pop/shift/append to arrays, merge two sets of key-value
pairs with a priority system to decide who wins when there are
duplicates, etc.

Then, it has an emitter system to serialize those in-memory objects back
out to a config file.

The API is generic enough that the input and output formats could
include some type of database. One flavour that I am looking to add is
nvlists, as this appears to be the best way to pass data between modules.

As for the command line tool, this is the intention of uclcmd:

If you have /etc/pkg/FreeBSD.conf:
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}


You can do:


uclcmd get -f /etc/pkg/FreeBSD.conf FreeBSD.url

and the result is:
pkg+http://pkg.FreeBSD.org/${ABI}/latest

And then you could do:

uclcm set -f /etc/pkg/FreeBSD.conf FreeBSD.url
http://pkg.mysite.com/${ABI}/custom

And it would modify the configuration in place for you.

Although some limitation in libucl mean that, if you have a config that
has comments in it, the comments are lost, as they are not represented
in the in-memory version of the object that then gets serialized for
output. If you treat the config files as a database, then this is fine,
but if the user expects to still hand edit them with an editor, this is
a fairly big POLA violation.

-- 
Allan Jude

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20151120/7d54935f/attachment.bin>